File recursion limitation

[AdrianH]

It seems that boost's file recursion requires that the file using the recursion must be in the include path. This makes using file recursion in a library header a problem as libraries may be located in a subdirectory of an include path (which is minor since the programmer can state the subdirectory in the recursive file call as long as it is not relative to the calling file). I also found it a problem when the main compile directory isn't in the compile path.

Does anyone see this in the documentation anywhere? Is this just a failure of not seeing this as a problem?

[helios]

What exactly do you mean by "file recursion" and "recursive file call"?

[AdrianH]

Boost calls this vertical repetition. (See section A.4 of http://www.boostpro.com/mplbook/preprocessor.html)

My problem is that it doesn't work with a relative file inclusions or if the file from which you are using for this is not in or relative to an include directory.

I'm currently working on a system that is similar to Boost that will handle this and it's almost done, but I was wondering if anyone else had run into this problem?

[helios]

Geez. Those Boost people are crazy.

Probably a dumb question, but I have to ask: you do know that #include "path" looks for "path" relative to the file that contains the directive, right?

[AdrianH]

Crazy... like a fox. ;) It is actually quite a powerful mechanism for doing repetitious boiler plate code which can have it's maximum change by only changing a define.

Yeah, I do know about that the path is relative. However, if you include a file that is not in the current file's directory, and that file then tries to include your file given the filename that you specified, it won't know where that file is if that file is not located in a path relative to the any of the include directories. Did you get that? :)

Say the include directory set is { /include/path1 }

// FILE: source/path/file.h
#if !defined FILE_H
# define FILE_H
# define INCLUDE_ME "file.h"
# include <includeMe.hpp>
#else
Callback succeeded!
#endif 

// FILE: /include/path1/includeMe.hpp
#include INCLUDE_ME 

This won't work, since file.h is not in the set of include paths. If I had set INCLUDE_ME to "source/path/file.h", it still won't work since relative to the include paths it doesn't exist, unless it was located under /include/path1/source/path/file.h, which for this argument, it does not.

We may be able to remove this completely if all C++ compiles use variadic templates. However, this is a long way off since there are older system around.

[helios]

Ah, okay, I got it.

Yeah, there doesn't seem to be any way around that. I don't think this mechanism was designed to include files not in the project directory.
If possible without breaking stuff, I would just create a symbolic link to the header in source/path.

[AdrianH]

No, this limits reusability. I'm almost done making my implementation generic.

[JLBorges]

> It seems that boost's file recursion requires that the file using the recursion must be in the include path.

Yes. Or the path must be specified relative to a directory in the include path.

I haven't used this library, except trivially.
If we compile with the options g++ -I. -I/ can't any file be specified?
Either relative to the root of the filesystem (-I/) or relative to the main compile directory (-I.).

[AdrianH]

No, unfortunately, that's not an option. And having it not relative is kinda clunky anyway. :(

I had almost finished my own version that works relatively, but I got stuck trying to figure out this:

 # include <boost/preprocessor/cat.hpp>
 #define REL_ITERATION_1 1
 #define REL_FRAME_ITERATION(i) BOOST_PP_CAT(REL_ITERATION_, i)
 #define REL_ITERATION_PARAMS_2 REL_FRAME_ITERATION(1)
 #define REL_FRAME1(i)           BOOST_PP_CAT(REL_ITERATION_PARAMS_, i)
 #define REL_FRAME2(i)           REL_ITERATION_PARAMS_##i
 REL_FRAME1(2)
 REL_FRAME2(2)

I think that the last two lines should give the same result, but it doesn't. Do you know why?

[JLBorges]

> Do you know why?

No. I haven't used this library at all (except indirectly).