Boost logo

Boost-Build :

From: David Abrahams (dave_at_[hidden])
Date: 2002-09-11 08:49:31


From: "Vladimir Prus" <ghost_at_[hidden]>

> David Abrahams wrote:
> > From: "Vladimir Prus" <ghost_at_[hidden]>
> >
> >>>That rule seems a little too trivial to be correct. Don't you care
what
> >>
> > the
> >
> >>>#include path is?
> >>
> >> > What if that particular a_parser.h wasn't intended?
> >>
> >>Ok, you can check if the current dir is in path.
> >
> >
> > No way, dude: The contents of the header might well depend on the
toolset
> > and build variant!
>
> And what's the problem? If the user has "a.cpp" and include path for it
> includes the "a.cpp"'s directory, and the generated file will be found
> if it's generated to that dir. We generate it to different dir, so we
> need to make sure it will be picked up properly.
>
> One variant will have include paths tweaked so that include one version
> of the header. Another variant will include another version.
>
> However, if "a.cpp" includes a_parser.h via <> and "." is not in the
> search path, we won't do anything about this file.
>
>
> >>I don't think much more
> >>complexity is needed. User expects everything to work as if the file
> >>were generated in the current dir.
> >
> >
> > I don't think so, not at all.
> > Do you really mean the "current" directory, AKA "./"?
> > Or do you mean something else?
>
> I mean the directory where including file lives.

Oh, OK! I like this rule.

-----------------------------------------------------------
David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com

 


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk