Re: Separate obj tree

[Steven Knight]

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