[SF]VM building project third report

Lex Spoon lex at cc.gatech.edu
Thu Jun 13 18:41:16 UTC 2002


Ian Piumarta <ian.piumarta at inria.fr> wrote:
> On Mon, 10 Jun 2002, Lex Spoon wrote:
> 
> > Ian Piumarta <ian.piumarta at inria.fr> wrote:
> > 
> > >(In particular, the "makeMakefileFragsAndProveFermatsLastTheorem"
> > > scripts are irrelevant to [and ignore entirely by] my build process --
> > > which I hope is now infinitely simpler than anything that grew out of
> > > the original "unholy 3.1 mess".)
> > 
> > The system on SourceForge is better in two ways:
> > 
> > 	1. It avoids recursive make.  All the make rules are combined into a
> > single Makefile at the top level.  I'm baffled at why people are
> > resistent to this, except that the Unix tradition is to do it otherwise.
> 
> With the new scheme you can "cd" to a subdir in the build directory and
> type "make" and it just works.  (I think. ;)
> 

In my scheme you can type "make FooPlugin.la".  In fact, you can type
"make anydir/anyfile" and it will work correctly.  This simplicity and
clarity is one direct result of avoiding recursive make.


Have you read the following page?

	http://www.tip.net.au/~millerp/rmch/recu-make-cons-harm.html

I don't want to repeat all of it here.


By the way, note that non-recursive make is an idea that you could
integrate by itself, independently from whether you allow plugin authors
to use scripts.


> > 	2. It generates makefiles from scripts instead of requiring
> > hand-written files.  In fact, the bulk of the makefiles in Ian's release
> > are already generated from scripts, so I shouldn't need to list the
> > advantages.  What is so strange about going all the way?
> 
> Woah, hold on a minute.  NONE of these scripts is intended to ever be seen
> by a plugin developer.  (Find me ONE script that isn't in the "config"
> directory.  There aren't any.)

Of course.  I was simply appealing to you as someone who has generated
makefiles from scripts.  Isn't it nice having a real for loop?  Isn't it
nice to have subroutines?  Why not allow that power to plugin authors? 
Even GNU makefiles, with all their extensions, are a pain to write by
hand for large program.

This is a specific case of Olin Shivers's "little languages" argument:
don't embed programming commands into little languages, but instead
drive the little languages from an existing programming language.  Have
you read it?  I suspect the idea is familiar to anyone who has battled
with using GNU make extensions, even without reading this paper!

	http://www.cc.gatech.edu/~shivers/citations.html#ll



>  To specialise what a plugin
> configures/builds you just add the following to the platdep plugin dir:
> 
>    Makefile.inc       -- to add extra compile/link flags, etc.
> or Makefile.in        -- to rewrite the final "link" target
[....] 
> What could be simpler?  Look carefully at the contents of


Makefile.inc is an improvement, if it does what I think it does.  Wtih
that file, MPEGPlugin might not need acustom Makefile.in any longer. 
(Which means the script vs. raw file debate becomes fairly academic!)

Aside from that, my scheme is about the same except that Makefile.in is
a script.  In the simplest case you can just put "cat <<EOF" at the top
and "EOF" at the end and you have a script.   But you can also do more
powerful things, if you want to.  I'd think it very likely that you'd
want that power, if you are bothering to write custom build rules at
all.


> How long are the mkMake* scripts?  mkMakeRules just for Mpeg alone is 118
> lines (95 if you remove blanks).

Yes, I think it's a simplification.  Instead of belaboring the details,
let me just mention that historically, this used to be done with
hand-written makefiles.  I changed it to use a script because the script
seemed much simpler.  Having the script run automatically seems like a
natural step forward from that.

Note, by the way, that this script handles three cases: internal
compilation, external compilation, and compiling libmpeg by itself.  If
you take these cases out--not that you'd want to--the script will get
much shorter.


MPEG isn't the clearest example, though, because perhaps you had to
suffer the pain of the previous makefiles to see the improvement. 
Consider JPEG and libjpeg, instead.  With JPEG, it would be nice to use
the system's libjpeg if it is present.  After all, maybe that libjpeg
has some platform-specific optimizations compiled in.  Also, it is
likely to be more up to date than whatever version we have copied into
CVS.  How would you do this?  If the makefile comes from a script, then
you can check whether libjpeg in installed and compile in a different
fashion if it is.  If the makefile is hand-written, or if it is
generated using the default rules, then you have to have it one way or
the other.  Isn't it nice to have the option to use a script?


> > Both systems are equally complicated.  Perhaps there is a lack of
> > understanding?
> 
> Please, before saying the new scheme is as complex as the old, read the
> HowToBuildFromSource document.  And if you've already read it and still
> think it's complicated then yes: there _is_ a lack of understanding.
> 

I think I see how your system works.  I's not actually much different
from your 3.1 system, is it?   I don't see how you can say it is
significantly simpler.  Changing scripts to raw files is only a tiny
simplification that comes with a significant reduction in power.  Using
recursive make seems no simpler than using integrated make -- perhaps
it's even more complicated, depending on how you look at it.



> > There are docs now in CVS that explain it all -- look
> > for "BUILD.details" in the Unix area.  It doesn't have any design rationale,
> > but it does describe what is present currently.
> 
> Good luck with it.  Nobody is forcing you to change.

It's important because if everyone wants to use your system, I'll go
along with it.  I think mine has some parts that are clear improvements,
though, and I'd hate to see them get lost.

To summarize, mine has:

	1. Including sub-makefiles into the top-level makefile, to avoid
recursive make invocation.

	2. Allowing scripts for the sub-makefiles.


Yours has Makefile.inc, which is also a nice improvement on the 3.1
build system.


Lex



More information about the Squeak-dev mailing list