Re: [boost] Re: Re: MPL include problem with BOOST_PP_ITERATE

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2003-01-27 15:42:14

----- Original Message -----
From: "Hugo Duncan" <hugoduncan_at_[hidden]>

> > At one point in the past, however, I wrote a mechanism explicitly for
> > including a set of files.  It was intended to "shorthand" the process of
> > including a lot of files from the same library.  Something like:
> >
> > #define BOOST_PP_HEADERS \
> >     (boost/preprocessor,
> > (tuple/elem.hpp)(repetition/repeat.hpp)(list/adt.hpp)) \
> >     /**/
> >
> > #include BOOST_PP_ANGLED_INCLUDE()
> >
> > (I had BOOST_PP_QUOTED_INCLUDE as well.)  I'd be happy to add such a
> > mechanism, but I'd like to hear what people want from the mechanism and
any
> > thoughts on syntactic issues, etc..
>
> BOOST_PP_xx_INCLUDE( directory, list_of_filenames_with_paths ) is
> good as long as directory can be empty, for the case where the filenames
have
> different paths.

BOOST_PP_xx_INCLUDE(directory, files) is impossible.  What you need is a
user-defined macro that contains the files that you want, and then include
another file that performs all the inclusion.  The mechanism that I had
handled the "no path" case by using parentheses.  For example, (I don't
remember the exact syntax that I had, so forgive me if it changes from post
to post.  The syntax is, of course, open for discussion.)

#define BOOST_PP_HEADERS \
    (...), /* i.e. "no path" */ \
    (iostream)(fstream)(vector)(string) \
    (map)(cstdlib)(sstream) \
    /**/

??=include BOOST_PP_ANGLED_INCLUDE()

...effectively does this:

#include <iostream>
#include <fstream>
#include <vector>
#include <string>
#include <map>
#include <cstdlib>
#include <sstream>

> The other problem that I have when using this is that it removes
> dependencies for the build process.  To solve this, the files can
> be preprocess.  Is there a standard toolset/method for preprocessing
> header files ?

I'm not sure what you mean here.  The arities, and possibly other things,
that the MPL can handle is directly dependent on certain macros.  If you
pre-preprocess the files, you effectively fix the arities to a certain size.
Also, you'd have to preprocess the files separately for each compiler that
you want to target.  Worse, you implicitly undefine all macros
used--including include guard macros.

You can simply make a source file that includes all the files that you want
to pre-preprocess (if that is what your getting at), run it through your
compiler's preprocessor, and then include the result file.

...but this is outside the scope of the pp-lib can automate because it
requires a separate build step to produce the preprocessor equivalent of a
"pre-compiled header."

Paul Mensonides