Boost logo

Boost Users :

Subject: Re: [Boost-users] [wave] Custom I/O handling (include paths, etc.)?
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2011-04-07 20:07:34


> I'm not sure how exactly it should look like, but I guess the interface
> should be part of the input policy, as they have to work in tandem.
> Basically, you call an input policy function which returns true/false
> depending on whether it can open a given include file (providing the
> include paths, system include paths and the include type to it.) If the
> input policy returns true, then it must also return the full file path.
> The full path is then passed back into the input facility via the context,
> as usual.
> That should do the trick, unless there's more hidden I/O that I didn't
> find yet.

Sorry for the long delay in answering. I now added a new preprocessing hook
exactly as you suggested:

    // The function 'locate_include_file' is called, whenever a #include
    // directive was encountered. It is supposed to locate the given file
    // should return the full file name of the located file. This file name
    // is expected to uniquely identify the referenced file.
    // The parameter 'ctx' is a reference to the context object used for
    // instantiating the preprocessing iterators by the user.
    // The parameter 'file_path' contains the (expanded) file name found
    // the #include directive. This parameter holds the string as it is
    // specified in the #include directive, i.e. <file> or "file" will
    // in a parameter value 'file'.
    // The parameter 'is_system' is set to 'true' if this call happens as a
    // result of a #include '<file>' directive, it is 'false' otherwise,
    // for #include "file" directives.
    // The parameter 'current_name' is only used if a #include_next
    // was encountered (and BOOST_WAVE_SUPPORT_INCLUDE_NEXT was defined to
    // non-zero). In this case it points to unique full name of the current

    // include file (if any). Otherwise this parameter is set to NULL.
    // The parameter 'dir_path' on return is expected to hold the directory

    // part of the located file.
    // The parameter 'native_name' on return is expected to hold the unique

    // full file name of the located file.
    // The return value defines whether the file was located successfully.
    template <typename ContextT>
    locate_include_file(ContextT& ctx, std::string &file_path,
        bool is_system, char const *current_name, std::string &dir_path,
        std::string &native_name);

Wave does not use the native_name returned from this hook for nothing else
as to pass it along to the input policy, which is supposed to open the file.
Therefore you can use this string for whatever encoding you like.

I hope this change (see SVN trunk) does not come too late for you.

Regards Hartmut

> Cheers,
> Anteru
> Am 20.03.2011 23:32, schrieb Hartmut Kaiser:
> >> I'm trying to adopt Wave as my custom preprocessor for a project. So
> >> far, things work fine, but there is one problem with Wave: I need to
> >> override all I/O functions, in particular, reading from files and
> opening files.
> >> Reading is easily changed by the input policy, but I couldn't find a
> >> way to register an include handler hook. There's
> >> found_include_directive, but nothing that allows me to get in-between
> >> wave and the filesystem. In my case, I on-demand construct some data
> >> which I want to be able to #include (i.e. #include <generated>) and
> >> some files are stored in resources/compressed files (#include
> <zip/file.h>).
> >> My include handler can open them, but how can I tell Wave to ask my
> >> include handler whether it can find a file instead of using
> >> boost::filesystem?
> >
> > Sorry, that's currently not supported.
> >
> > What interface have you been thinking to use? Any suggestions on how
> > such a facility could be integrated into Wave?
> >
> > Regards Hartmut
> > ---------------
> >
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at