RE: Cons with output in Separate Subdirectories.

[Greg Spencer]

(My apologies if this gets posted twice -- I sent it from the
wrong account the first time).

Hi Marcello!

        Welcome to Cons!

        Yes, of course cons can do what you describe, and in
a very simple way too -- you're just thinking "makefile" too
much.  Try thinking "perl script" a bit more, and things will
become easier. :-)

        To build your different variants, you simply need to have
multiple passes over the "Build" commands.

        Look at this piece of my Construct file (the top
level file):

-------------------------------------------------------------------
Export qw(CONS INCLUDE LIB BIN BUILD
          BUILDTYPE EXPORT DEFINES);

map(BuildConfig($_),@types);

sub BuildConfig {
    $BUILDTYPE = shift;

    # Where to put all our shared products.
    $EXPORT = "#export/$BUILDTYPE";
    $BUILD = "#build/$BUILDTYPE";
    $DEFINES = '/D "WIN32" /U "_WIN32_WINNT" /D "_WIN32_WINNT=0x0400" ';
    $DEFINES .= '/D "_DEBUG" /D "DEBUG" ' if $BUILDTYPE eq 'debug';
    $DEFINES .= '/D "NDEBUG" ' if $BUILDTYPE eq 'release';

    # character set selection
    # $DEFINES .= '/D "_MBCS" ';
    # Windows calls are conditioned on UNICODE rather
    # than _UNICODE, so define both
    $DEFINES .= '/D "_UNICODE" /D "UNICODE" ';

    # the '/Oy-' is so we can unroll the stack when debugging
    # a release build.
    $OPTFLAGS = (($BUILDTYPE eq 'debug') ? '/GZ /Od ' : '/Ob2 /Ox /Oy- ');
    $LDFLAGS = $CONSBASE->{LDFLAGS};

    # only on VTune compiler, only on release variant
    if ($param::compiler eq 'vtune' && $BUILDTYPE ne 'debug') {
      $OPTFLAGS .= '/QaxiMK '; # turn on MMX/SIMD optimization for
PII/III.
      $OPTFLAGS .= '/Qip '; # turn on interprocedure optimization
    }

    # Standard directories for sharing products.
    $INCLUDE = "$EXPORT/include";
    $LIB = "$EXPORT/lib";
    $BIN = "$EXPORT/bin";

    # build off the "base" CONS object.
    $CONS = $CONSBASE->clone( CPPPATH => $INCLUDE,
        LIBPATH => $LIB,
        DEFINES => $DEFINES,
        BIN2H => "$BIN/bin2h.exe",
        MCCOM => "$vc98/bin/mc.exe",
        OPTFLAGS => $OPTFLAGS,
        LDFLAGS => $LDFLAGS,
        THREADFLAGS => (($BUILDTYPE eq 'debug') ? '/MDd' : '/MD'),
        RCOPTFLAGS => (($BUILDTYPE eq 'debug') ? '/d "_DEBUG"' :
                       '/d "NDEBUG"'),
    );

    Link "$BUILD/tools" => "#tools";
    Link "$BUILD/lib" => "#lib";
    Link "$BUILD/cmd" => "#cmd";

    Build ("$BUILD/tools/Conscript");
    Build ("$BUILD/lib/Conscript");
    Build ("$BUILD/cmd/Conscript");
}
--------------------------------------------------------------------

Now, I only build "debug" and "release" variant builds, but
they could be anything.  You could even switch compilers (as
you are doing).  Notice that my "Build" statements are
within a function which is called once for each type of
build, and that inside that function I set variables based
on the $BUILDTYPE local variable.  BUILDTYPE is exported to
all of the lower level conscript files, as are many other
variables, so that they know what to build, and where to put
products.  That way, when you create all the other Conscript
files, they (usually) don't need to know anything about what
type of build it is.  If you need a different list of files
for different variants, of course, you'll need to have
conditionals (based on BUILDTYPE) in the Conscript files
that are lower down.

The "#build" and "#export" notation specifies a path that is
relative to the location of the Construct file.  That way
you can specify a file anywhere in the build tree without
having to remember how many "../.." to add, and it is still
location independent.  I use them in the above example to
"link" the source directories to the build directories.  On
an NTFS filesystem, it actually does use hard links, but (of
course) the MSDEV editor breaks that by deleting the
original file before saving.  If you use emacs (or just
about any other editor), then you don't even incur a space
penalty for having multiple links to a source file.

In the above example, debug intermediate files (the "build"
files) go into #build/debug/... and the release intermediate
files go into #build/release.  The final products of the
build (the "exported" files) go into #export/debug/... and
#export/release/...  This avoids having any build
intermediate files (*.obj, *.exp, etc.) in the source tree
or the export tree.  All the output products are "Install"ed
into the "export" tree, so that's where you find your
results.

You can also build using files that were built in this run
-- check out the "bin2h.exe" I have above.  You just have to
make sure that the input to this program depends on the
executable that is built and installed so that cons knows
that it has to build the executable before running it.

That should get you started.  If you have any problems, let
us know.  BTW, we're also working on making Cons more
win32-friendly.  It was originally designed to work on Unix
(much as "make" was), and it's taking a bit of work to
factor in all the windows craziness.

Good Luck!

                -Greg