Re: #include's and Quoting

[Dmitry Sagalovskiy]

I believe if you use repositories but whenever you have a local copy of
files, you have local copies of whole directories, then quoted #includes
will work, because both the compiler and cons will see the same files.
In other words, problems should only arise if files that are included with
#include "..." aren't in the directory where you are building, but only in
a repository directory. If you take advantage of the repository feature on
a directory-by-directory basis, then I don't think quoted includes will
give you problems.

I may be wrong, but that's how I explain the fact that we use cons with
repositories and #include "..." headers, and everything works fine.

d


On Thu, 6 Nov 2003, Steven Knight wrote:

> > > | [snip]
> > > | > I'm referring to the requirement that I change all my:
> > > | >
> > > | >   #include "blah.h"
> > > | >
> > > | > lines to be
> > > | >
> > > | >   #include <blah.h>
> > > | >
> > > | > in order to use repository trees.
> > >
> > > I believe the only place where this matters is if you use cons
> > > repositories (the -R option).  We use "" and <> freely and do not use
> > > repositories, and it's worked like a champ.
> > [snip]
> >
> > I believe the original question was how to work around this if they *do*
> > want to use cons repositories.
>
> The issue is that most (many?) C compilers *always* first search the
> local directory to a source file for any #include "..." files.  The
> repository support in Cons relies on putting the right -I options on
> the compilation command lines so that the repository directories are
> searched in the correct order.  The always-search-local-first behavior
> breaks that searching.
>
> The way to work around this would be if the compiler in question
> supports an option to disable the always-search-local-first behavior.
> If so, you can set that option in CFLAGS and it should find the right
> files regardless of whether you use #include "..." or #include <...>.
> Without such an option, I don't know of how you'd support a Cons-like
> repository feature in any build tool, because it's the underlying
> compiler behavior that's at odds with how repository is designed to
> work...
>
>         --SK
>
>
>
> _______________________________________________
> address@hidden
> http://mail.gnu.org/mailman/listinfo/cons-discuss
> Cons URL: http://www.dsmit.com/cons/
>