C++ header and impl files in different directories

[Brian Kuebert]

I've reverse engineered some C++ code.  Due to the large volume of directory hierarchy in the code, most of the headers have been thrown into a single include directory and the implementation files are scattered throughout the directory structure.

The code reverse engineers fine, however, if I change something in a class and then generate code the change only appears in the header file.  Am I doing something wrong or is this something that's not supported?

[«Midnight»]

Hi Brian,

I could be wrong on this, but I seem to remember that EA only supports a single directory for code output. [At least at any given time, since different packages can be in different sub-directories.] If memory serves, C++ (perhaps C) allow different file extensions where other languages allow only one per element, and they might handle reading the code and header from different places, but I don't think they allow the output to differ.

[edit]But wait!

Look at the Tools | Options | Source Code Engineering | C++ dialog. Near the bottom of the options list - below the 'Options for the current user' heading, you'll need to scroll down - you will see two interesting entries. They are not consecutive, but they are both near the bottom. I don't know if these affect code generation, but it's worth a shot.

The first is simply Default Code Directory. This is probably not important here. The second - at the very bottom of the list in build 830 - is Source Path. This field supposedly "Determines the search path for the implementation file, relative to the header path." Perhaps this will help. I note that it defaults to "./" which would produce the behavior you are experiencing.[/edit]

David

[Brian Kuebert]

Thanks, I'll give that a try.  Sounds like it will work for new code or if I manually configure, but this particular project consists of many, many implementation files and doing it all by hand is not what I was hoping for.

It probably won't be until Monday but I'll post back with what I discover.  Thanks!

[Eve]

David, your memory did serve correctly, but the second option you mentioned has since been added for just this situation.

As an example, if you have a directory 'inc' that contains all of your headers, while the source code is mixed through directories 'src', 'srca', and 'srcb'.  You will then want the option set to '../src/;../srca/;../srcb/'.  This will ensure that new implementation files are generated into 'src', but when parsing existing files EA will look in all three source directories (and never in the include directory).

You will still need to ensure that the implementation file name matches the header file name, and that the option matches the extension specified in the options.  If these conditions are not met, EA will not be able to handle that code.

[«Midnight»]

Thanks Simon,

Brian, with any luck at all this simplifies your problem in both directions. Depending on how your legacy code is (dis)organized, you should be able to go in both directions without too much trouble.

Yes, you still might need to move a few files, at least for the reverse engineering step. For forward engineering of your revised system you have some flexibility.

If that's not enough, I strongly suggest you ask the local powers for a specification of how they want thing arranged. I am talking about something with the level of rigor and soundness that would be required to support good code (not the usual stuff). If they can provide such a thing you have clear-cut start (from EA) and finish (from the specification) definitions to automate file movements. If they cannot you have an even better justification for configuring the revised system in a workable fashion rather than a best guess (i.e. unspecified) approach.

HTH, David

[Brian Kuebert]

Thanks for the help - I did get it to import my source code so I can round-trip engineer is successfully.

There actually is a reason for the odd organization of the code, so just saying "I'm going to reorganize the code to work with my UML tool" is not a valid option.  But it looks like I've got the problem solved and the tool has the flexibility I need.  Thanks!