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. ;)

> 	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.)  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
                         (note that all of the config and automatic
                         targets are generate for you: you just put
                         [make_cfg] and [make_targets] at the top
                         and bottom of the Makefile.in)
and/or
  acinclude.m4        -- which is sucked into configure.in just before
                         the AC_OUTPUT to find plugin-specific
                         libs/headers.

What could be simpler?  Look carefully at the contents of

  platforms/unix/plugins/
    JPEGReadWriter2Plugin/Makefile.inc
    MpegPlugin/Makefile.in
    MpegPlugin/acinclude.m4
    B3DAccelerator/acinclude.m4

Here's how long the above files are (in lines):

   3 devel/platforms/unix/plugins/JPEGReadWriter2Plugin/Makefile.inc
  31 devel/platforms/unix/plugins/Mpeg3Plugin/Makefile.in
   3 devel/platforms/unix/plugins/B3DAcceleratorPlugin/acinclude.m4
  15 devel/platforms/unix/plugins/Mpeg3Plugin/acinclude.m4
  52 total

and with blank lines removed the TOTAL for ALL plugins comes to 28 lines.

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

The above *.in[c] files are ALL a plugin developer EVER (under ANY
circumstances whatsoever) needs to add to the new Unix sources to get
arbitrary special treatment for their plugin.  Plugin developers never,
ever have to write scripts to generate bits of makefile or configure.  
The only person who ever has to worry about the scripts that generate
makefiles is me.  (And I assure you, being the person who wrote the old
scripts and the new scripts, that the new scripts are a lot easier to
understand and maintain than the old ones.)

Now tell me that the mkMakeFrags, mkMakeInc, etc. scripts that replace the
above in the old sources are in any way, shape or form "simpler".

FWIW, the "default" makefiles for plugins are built from templates that
are every bit as simple as the above "explicit" Makefile.in.  Look at
platforms/unix/config/Makefile.plg.in for the actual template used.

> 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.

> 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.  (OTOH, trashing the
old scheme was probably the single best move I ever made in the history of
Unix Squeak development.)

Ian