Simon Cozens <[EMAIL PROTECTED]> writes:
> On Thu, Oct 11, 2001 at 03:24:31PM -0400, Dan Sugalski wrote:
> > 1) Build minimal perl 6 with default parameters using platform build tool
>
> But "platform build tool" is going to be 'make' - the alternative is
> that we maintain and ship every flavour of batch or shell script we can
> think of. I don't think much of that.
>
> And if we have to use make, then we're back with the very problems of portably
> calling compilers and so on that this supposed new build system was meant to
> avoid.
You could write one front end like the one Robert suggested, and two
back ends:
back end A: writes a makefile, or a shell script, which will build
the specified targets.
back end B: checks dependencies itself, sequences the build,
and issues the commands (via system() or whatever)
Then you use back end A to create a makefile/script which you ship with
Parrot, and back end B will run on the target platform once the
miniperl6, or what will be there, is available.
The good thing is that you can share a lot of code between A and B,
namely the code which assembles the commands to issue (with all those
cute command line options which are not the same for two tools in the
world.) (see MIDDLE LAYER below)
I once wrote a tool called "MakeMake" in Perl5 which writes makefiles
and has a front end very much like Robert's suggestion (My front end is a bit more
complex, because it has a two level system of "attributes" and
"properties". I don't know if I would do it again this way if I wrote
it today.)
What I learned doing that:
The only way to keep sane here is to exploit orthogonality as much as
possible. IMO the design shoul look like this:
1) FRONTEND
- parses the input files
- fills up any information not supplied by the input files with
sensible defaults (one usefull strategy is a kind of
inheritance: an object file inherits attributs from the
library it will be in, the library inherits attributs from
the project-global input file, ...)
The main purpose of the FRONTEND is to relieve the MIDDLE
LAYER of the need to 'special case' all the time for different
kinds of input.
2) MIDDLE LAYER
- This layer provides abstractions for all the tools you need
in the build. There should be abstract base classes
MakeTool
Compiler
LibTool
LinkTool
...
from which specific implementations are derived. eg.
LinkTool::GNUld
LinkTool::MicrosoftLINK
LinkTool::BorlandTLINK
It is *very* important, that you don't throw all these
together into monolithic "Platform"-implementations. You
will hate yourself later if you do that (I did it the first
time :)
There should also be an abstraction for the "build platform"
which provides:
commands for copying, (re)moving, creating directory
structures, etc.
Maybe "Shell::" and "OS::" classes would be
appropriate. (Always remember: make it as orthogonal as
possible!)
3) BACKEND
see backends A/B above
There is yet another instance of orthogonalty to exploit. This time
it's about the input files. There should be independent files for:
I1) ENVIRONMENT
- The structure of the source tree (you may want to build only
parts of it, so don't use absolute paths. My "MakeMake" uses
only absolute pathnames, so I wrote a cheesy system which
assembles paths from several parts which can be specified in
any order.)
- The location of external libraries
This may have to be customized if you move your source base to
another development machine. The environment files could also
be written by a Configure.pl like tool.
I2) BUILD INSTRUCTIONS
which objects, libraries, shared libs, executables to build
and from what.
This should not have to be customized to a development
environment. (Except things like: "don't build this utility on
Win32", ...)
Please don't ask me to show the MakeMake source, it would be so
embarassing. I wrote it some years ago and drew all the design
conclusions above *afterwards* :) If you will ask, however, I will
expose MakeMake for the good of Perl6 (under LGPL or
something). Consider it more an example, of where not to go.
-Edwin
