Re: Separate obj tree

[Bob Sidebotham]

As I recall, I was responding to you in the context of your remote
repository project that you were embarking on. It seems to me that if
you enforce the rules required for the repository, then that could
extend to linked directories. In other words, you could view the source
directory as the repository for some of the source files. Or is "some
of the source files" a problem here?--the repository that you link to
has, of course, all the derived files intermingled with the source
files.

Bob

--- Steven Knight <address@hidden> wrote:
> On Fri, 29 Sep 2000, Kolarik, Tony wrote:
> 
> > Has anyone created a build with a Link() like capability that
> creates a
> > duplicate "source" tree without the sources, just the objects?  
> > 
> > On NT all the files get physically copied to the Linked tree.  I
> know disk
> > space is cheap, but I'm curious how feasible a separate object tree
> would
> > be.  Off the top of my head I can't think of a compelling reason
> why the
> > sources need to be Linked, even on a system with real file links.
> 
> Bob Sidebotham addressed why Cons behaves this way in a message from
> the very early days of the mailing list (another reason why we need a
> publicly-accessible archive!):
> 
>       Date:    Tue, 14 Apr 1998 11:38:35 -0400
>       From:    Bob Sidebotham <address@hidden>
>       Subject: Re: Examples 
>       
>       >One thing I'm still sometimes confused
>       >about is files in subdirs; for instance, why does cons hard-link
>       >source files into the build subdirs but not cd there to do the
> build
>       >(instead, it uses the relative pathnames for both source and obj
>       >files)?  This is something I'd think might be optional, one
>       >alternative being to put only the objs in the build dir and use the
>       >real source file like 'cc -o build/foo.o foo.c'.  But I suspect
> there
>       >are good design reasons why this is set up the way it is.
>       
>       There were several reasons:
>       
>       - - this arrangement makes it possible to scan an error listing and
> find
>       the actual source files that have errors, since the name is complete
>       (this is especially useful for automated utilities that deal with
>       error messages).
>       
>       - - your example above would probably really be:
>       
>               cc -o ../build/foo.o foo.c
>       
>       and the number of ".."'s would increase as the directory depth
>       increased. This is not, in my opinion, significantly better than
> what
>       Cons actually does.
>       
>       - - finally, and most importantly, I wanted the semantics of
> #include to
>       be identical to what you get if you compile in place in the source
>       directory (this argument also extends to other utilities besides the
> C
>       compiler). The problem is this: if I include a file with #include
>       "foo.h" and foo.h is generated, then I would have to change the
> build
>       line to something like:
>       
>               cc -o -I. -I../build foo.c ../build/foo.o
>       
>       The -I. is also required because if a header file includes another
>       header file, then most C compilers will start the search for the
>       header file in the directory containing the header file, not ".".
> Now
>       this would be OK if it didn't affect other semantics. But the -I
> flags
>       will cause files included using #include <...> (rather than #include
>       "...") to be interpreted differently (rather than avoiding the local
>       directories, those directories are now searched).
>       
>       By using links, the build directory looks identical to the source
>       directory, and the semantics end up being identical.
>       
>       It's worth noting, by the way, that Cons is aware of these include
>       semantics, but that the semantics are hard-coded. If your compiler
> has
>       different include semantics (and, in particular, if you rely on
> those
>       differing semantics), then both dependency checking and creation of
>       the links in the build directory could work incorrectly.
>       
>       Bob
> 
> 
> _______________________________________________
> address@hidden
> http://mail.gnu.org/mailman/listinfo/cons-discuss
> Cons URL: http://www.dsmit.com/cons/


__________________________________________________
Do You Yahoo!?
Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free!
http://photos.yahoo.com/