Hi Steven and Tony,
So, I've started implementing a "builder" based version of
cons. It doesn't really work yet, but I think I've
successfully separated out the legacy stuff from the "new"
stuff, and I've decided that I can make it so that all
people have to do is require "cons-legacy.pm" in their top
level Construct to get the old behavior back (in addition to
the new bahavior, actually).
I've started implementation using Steven's idea that there
shouldn't be a distinction between "Converters" and
"Condensers", since I think he's probably right (and I
figured that if he wasn't, it would be impossible to
implement correctly, and be a good proof).
The main part of the interface so far is a cons package
method "Process" (I wanted to use Build, but that was too
much like main::Build). It takes one or two arguments: if
it has an arrayref as the first argument, and no second
argument, then it assumes that it is a list of source files
that need to have corresponding files created for them (a
one-to-one mapping, i.e. a compiler). If it has an arrayref
and a scalar as arguments, then is assumes that it is to
"condense" the array of files into the output scalar (a
many-to-one mapping, i.e. a linker). It can also be just a
single scalar, which it treats as the "one-to-one" case, or
two scalars, in which case it treats it like the
"many-to-one" case, but where "many" is just one. Hopefully
this won't be too confusing, and will just "do what you
want".
In order to configure this in a more individualized way,
I've removed all of the configuration in "@param::defaults",
and moved it into the legacy stuff (where it pushes stuff
onto @param::defaults), and replaced it with the following:
---------------------------
# Default environment.
# Includes maps for commonly built targets, using
# the builders defined in the "Builder" package.
# If you're looking for defaults for the individual builders,
# look in the builder class you're interested in.
{
my $CPPScanner = new Scanner::CPP;
my ($CXXCompiler, $CCompiler, $Linker, $Library, $SharedLib);
if ($_WIN32) { # use different defaults if we're on Windows.
$CXXCompiler = new Builder::Compiler::Win32CXXCompiler;
$CCompiler = new Builder::Compiler::Win32CCompiler;
$Linker = new Builder::Linker::Win32Linker;
$Library = new Builder::Archiver::Win32Library;
$SharedLib = new Builder::Linker::Win32SharedLibrary;
}
else {
$CXXCompiler = new Builder::Compiler::UNIXCXXCompiler;
$CCompiler = new Builder::Compiler::UNIXCCompiler;
$Linker = new Builder::Linker::UNIXLinker;
$Library = new Builder::Archiver::UNIXLibrary;
$SharedLib = new Builder::Linker::UNIXSharedLibrary;
}
@param::defaults = (
'BUILDERMAPS' => [ 'OUTPUTMAP', 'INPUTMAP', 'SCANNERMAP' ],
'OUTPUTMAP' => {
"$_o" => $CXXCompiler,
"$_exe" => $Linker,
"$_a" => $Library,
"$_so" => $SharedLibrary,
},
'INPUTMAP' => {
".c" => $CCompiler,
},
'SCANNERMAP' => {
'.c' => $CPPScanner,
'.s' => $CPPScanner,
'.S' => $CPPScanner,
'.C' => $CPPScanner,
'.cc' => $CPPScanner,
'.cxx'=> $CPPScanner,
'.cpp'=> $CPPScanner,
'.c++'=> $CPPScanner,
'.C++'=> $CPPScanner,
},
);
}
---------------------------
This allows the handler for each type of input file to be
specified as a result of the output that builder creates.
In the "Process" funtion, the builder that is used for a
particular file type is determined as follows:
1) for each input file, if there is an entry in the
"INPUTMAP" for that filetype, then that builder is
used.
2) if not, then each of the output handlers is asked if
it can take that kind of input. If there is more
than one builder that can take that type, cons dies:
it must be explicitly set out in the input map.
3) for each input file, the set of output files is
determined by asking the newly determined builder,
and,
4) the union of all the output files from all the input
sources is returned as an array.
Scanners for each of the input file types are determined by
the scanner map.
Now, I've reached a crossroads, and I'm wondering which way
to go... In order to configure each of the builders
separately (which is actually quite necessary, in order to
allow the full range of possibilities), I can either 1) go
the OOD way, and provide accessors for each parameter,
hiding the actual command-line flags from the user (and
instantly making it a lot easier to do multi-platform
builds), or 2) I can just provide a way to modify the
"environment" for each of the builders, and allow them to
interpret it any way they want, maybe making some standard
variable names along the way.
I'm thinking that if I follow the OOD way to modify a
builder, you do something like this in the Conscript files:
--------------
Import qw(INCLUDE LIB BIN CONS BUILD DEBUG);
@SRCS = qw(foo.cxx bar.cxx);
$cons = $CONSBASE->clone();
$cons->GetBuilder('.cxx')->PushInclude("#sdk/include");
$cons->GetBuilder('.cxx')->SetPrecompiledHeader("LibPCH.h",
"LibPCH.cxx");
$cons->GetBuilder('.cxx')->SetOptimized($DEBUG);
@OBJS = $cons->Process(address@hidden); # build the OBJs
$cons->Process(address@hidden,'foo.exe'); # build the executable
--------------
Now, I know it seems a lot more verbose than what we've had
before, but I'm pretty sure its a lot more powerful. For
instance, there's no indication of what platform this is, or
what compiler -- that's all handled when the builders are
configured in the mappings. Also, some elements could still
come out of the cons environment. For instance, we could
have a standard cons environment variable for preprocessor
defines, and we would still be using the PATH and other
things out of the cons ENV (just as we do now).
Of course, we could also define some shortcut methods for
building programs, shared libs, etc, that would condense the
last two lines into one line.
On the other hand, here's how I think an environment-based
configuration would look:
--------------
Import qw(INCLUDE LIB BIN CONS BUILD DEBUG);
@SRCS = qw(foo.cxx bar.cxx);
$cons = $CONSBASE->clone(
'.cxx' => [ PCHHEADER => 'StdAfx.h',
PCHSRC => 'StdAfx.cxx',
OPTIMIZE => $DEBUG,
CPPPATH => $cons->GetBuilder('.cxx')->
{CPPPATH}.";sdk/include" ]
);
@OBJS = $cons->Process(address@hidden); # build the OBJs
$cons->Process(address@hidden,'foo.exe'); # build the executable
--------------
I think that although I can see that we could do similar
things with this method as we could with the OOD method, it
seems easier to standardize an interface on an object
(i.e. PushInclude, SetOptimize) that it is to standardize
the environment variables (CPPPATH, OPTIMIZE). In reality,
it's not really all that different, it just feels like an
interface is more "permanent" than a varaible name (Note
that in the OOD example, the methods there are probably
methods on the Builder::Compiler base class, and not on
Builder.)
Things I really like about the OOD approach:
1) it's more platform independent
2) I really like the idea of not having to worry
about path separators in an include path.
3) It's easier to make changes to all builders in a class at
once, (assuming the changes can be made in a base
class).
4) there's a clear hierarchy and API for builders, so adding
in new ones should be more straightforward.
5) Adding in things that aren't compilers/linkers/archivers
should be easier, since they can each have their own API.
6) Adding new compilers/linkers/archivers should be easier,
because a base class should be able to handle most of the
basic API for you, and you just need to implement the
differences.
7) it can make things more "automatic", so that when you, say,
turn on debug mode, it can automatically change preprocessor
defines.
Things I don't like:
1) it's more verbose.
2) it's different than methods we've been using (i.e. hash
array assignment lists).
3) a plethora of API could make things harder to keep in
your head (although a plethora of environment variables
could be just as bad, and people are more likely to
document API).
I'm still leaning towards to OOD method, because of its
power, but I'm not totally conviced that others will want
that -- they may be more comfortable with the environment
list.
Any opinions/comments?
-Greg.
smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---