Project build options / Search directories

[bnilsson]

Hi!

Is there any way to make Compiler / "Search directories" go into subdirectories?
If the sources are structured in subfolders, there may be a lot of entries.

[MortenMacFly]

Is there any way to make Compiler / "Search directories" go into subdirectories?

This depends on the compiler, but I don't know any compiler that supports such.
And if a compiler would support such this would be very bad programming.
With regards, Morten.

[bnilsson]

And if a compiler would support such this would be very bad programming.

Well, Codewarrior supports it (but you have the control to turn it off, of course! and it is quite handy.

But this would be a feature of the IDE, not the compiler itself, the subject of this entry was misleading. As you can see, I changed the subject line, I hope this is not regarded as bad manners here.

Maybe a clickbox "Expand subdirectories" in the "Project build options / Search Directories / Add" that would add the directory and all its subdirectories into the list.
That would not put any special requirements of the compiler.
Personally, I would appreciate such a feature, but maybe I am the only one.

[dmoore]

bnilsson: setting up c++ projects with a heavily nested structure of #includes sounds like a mess and is likely to create problems for you in the long run. even the biggest libraries shouldn't need multiple levels of nested subfolders of includes.

the more standard use of sub-folders is to create a pseudo-#include namespace to avoid #include-ing identical filenames for commonly used header names and to create logical groupings of functionality (e.g. wxWidgets puts all of its standard headers in <install-path>/include/wx, but you are only supposed to use <install-path>/include as the search path and then #include <wx/window.h> etc). Also keep in mind the you can create headers whose sole purpose is to #include a collection of commonly used headers (e.g. Code::Blocks own sdk_common.h)

[MortenMacFly]

Coming back to the compiler: I thought you mean something like a "-IR" command line switch for recursive includes or something (I'm aware that it can't be that easy).

Maybe a clickbox "Expand subdirectories" in the "Project build options / Search Directories / Add" that would add the directory and all its subdirectories into the list.

Hence you obviously mean the GUI part. For this I agree with dmoore here. Adding such a feature is no problem at all. But the use of such would be really error prone for several reasons. You may want to add a feature request for this to BerliOS so that the dev's can discuss it. But from my point of view I'd say it's unlikely that this feature would be implemented... such "feature" is actually "bad practice".

With regards, Morten.

[bnilsson]

I always respond to valid arguments, thanks.

Just to clarify:
What exactly is the bad practice?
Is it to structure the different source/header files in subdirectories according to function? wxWidgets, CB and may others does this...??
Or is it to refer to each subdirectory with its own path in the search list?

[MortenMacFly]

What exactly is the bad practice?

You should only add path's to include directories that are really required. Even such a complex framework as wx requires one (or two) includes. So settings up include path from a "root" including all sub-path's makes no sense in most cases. In fact it will lead in to trouble for sure some time in the future. Just one example scenario:
Imagine the following directory structure:

Code

MyProject
- include
  - lib_a_v1
  - lib_a_v2
  - lib_b

If you setup the include path's as required which maybe here:
1.) include
2.) include\lib_a_v2
3.) include\lib_b
You will never run into trouble, even though you have to setup 3 directories.
If you setup the path's recursively starting from "include" it will result in:
1.) include
2.) include\lib_a_v1
3.) include\lib_a_v2
4.) include\lib_b
Now imagine the changes from lib_a_v1 to lib_a_v2 were an additional member in a structure. You won't receive any compilation errors when the first "definition file" (header files that defines the struct) is found in lib_a_v1. This would be th case as the compiler would first find it there due to the order of the include command line switches (alphabetically) in this example case). Hence if you rely on sizeof(mystruct) for any reason you compile possibly buggy code.
So *you* should ensure you always setup the right directories yourself, even if these are many and not leave it up to any IDE. In addition I have never seen any project that requires more then let's say 10 include directories. So it shouldn't be too hard to setup those step-by-step. However - That's only my personal opinion.
With regards, Morten.

[bnilsson]

Ok, i think I get the point.

What would you think of a compromize: Allow multiple selections in the Project build settings / Search directories / Add dialog?

It would make life a little simpler, without putting the project in the hands of an unsuspecting IDE.

[MortenMacFly]

Allow multiple selections in the Project build settings / Search directories / Add dialog?

This would be an easy change: You need to change the construction of EditPathDlg in compileroptionsdlg.cpp and activate the boolean flag "allowMultiSel" in the dialog construction.
Thus for compiler/linker include dirs you need to change (starting at line 1312 in r4247):

Code

    EditPathDlg dlg(this,
            m_pProject ? m_pProject->GetBasePath() : _T(""),
            m_pProject ? m_pProject->GetBasePath() : _T(""),
            _("Add directory"));

...into:

Code

    EditPathDlg dlg(this,
            m_pProject ? m_pProject->GetBasePath() : _T(""),
            m_pProject ? m_pProject->GetBasePath() : _T(""),
            _("Add directory"), _T(""), true, true);

This is untested. You may want to try and (if it works properly) create a patch out of it and submit it to BerliOS.
With regards, Morten.

Edit: Of course you need to handle multiple path's then in the code that follows after this in the method. Look how it's done on other places.