RE: Changes to make fptools insfrastructure usable for standalone libraries

> I've been trying to use the existing fptools infrastructure (i.e., 
> configure.in and mk/*.mk) to build standalone libraries.  
> That is, I'm aiming 
> at the situation where someone has already installed ghc, 
> greencard, happy, 
> and all the other build tools they might need and now they 
> want to install 
> libX11 using a canonical sequence like:
> 
>   tar zxvf libHSX11.tar.gz
>   cd libHSX11
>   ./configure
>   make depend
>   make
>   make install
> 
> which will build the library and install the package.
> 
> Hopefully you agree that this is a desirable goal (if it 
> doesn't messup ghc too much).

Definitely a desirable goal.

You may find that the current build system isn't quite modular enough to
support this - there's too much project-specific stuff in the generic
mk/*.mk stuff for my liking.  We might be able to work around it for now
though.

Most of the problems you've encountered are to do with the fact that the
build system sets up the libraries to work with the in-place GHC build
rather than an installed GHC build.  It's actually slightly more
complicated that this, because it also sets up the packages for a GHC
build that will be installed later (hence the separate
package.conf.inplace and package.conf.installed files).

I think the right way to fix this is to introduce a toggle that selects
between the current behaviour and a mode which builds packages
specifically for use with an pre-existing GHC installation.  Let's call
this "standalone package mode".

> 1) fptools/mk/target.mk
> 
>    At the moment, the depend target depends on $(STAMP_PKG_CONF)
>    which is built when libraries are installed using ghc-pkg.
> 
>   This puzzles me because I can't install before I build the 
> library and I 
>   can't build the library until I 'make depend'.  I think 
> this dependency
>   should be dropped

The $(STAMP_PKG_CONF) should be done at boot time rather than install
time, because it sets up the in-place compiler to work with the package.
This is behaviour you want to turn off in standalone package mode.

In standalone package mode, you want to have a new rule that runs the
installed ghc-pkg to register the package, at install time.  The
configure script needs to detect the installed ghc-pkg, too.

> 2)  fptools/mk/path.mk
> 
>    At the moment, files are installed using the install-sh script but
>    directories are installed using mkdirhier.
> 
>    I'd like to drop this dependency so that the build 
> infrastructure can
>    omit this program.  As far as I know, install-sh -d is a 
> fine alternative.

Configure picks the 'install' program instead of install-sh if it is
available, and I don't know if all installs support the -d flag.
Probably safest to leave this as it is?

>    [How much of the glafp-utils infrastructure do I actually need?
>    I'm not sure but I think mkdirhier is the only tool which isn't 
>    provided in a debian/ redhat/ etc package.  Obviously, if 
> it turned out
>    that some of the glafp-utils were indispensible, this change would
>    be less compelling.]

glafp-utils/mkdependC is quite an important tool, too (at least if you
have any C sources).  We could perhaps have a cut-down glafp-utils with
just these essential tools.

> 3) fptools/mk/package.mk
> 
>   [diffs are long so they're appended to end of mail]
> 
>   package.mk contains many references to things defined in 
> ghc/mk/paths.mk:
> 
>    GHC_INCLUDE_DIR
>    GHC_DRIVER_DIR
>    GHC_PKG_INPLACE
>    GHC_INPLACE
> 
>   I have hacked round these references by inserting ugly code like:
> 
>     + ifeq "$(GHC_INCLUDE_DIR)" ""
>     + GHC_INCLUDE_DIR=<whatever>
>     + endif
> 
>   Ideas on how to clean this up welcome.

Ok, let's assume we have a $(STANDALONE_PACKAGE) toggle as I mentioned
earlier.  Then:

  - GHC_INPLACE: you should be using $(GHC) instead.  Or perhaps even
    $(HC), but I suspect there are lots of other GHC dependencies.

  - GHC_DRIVER_DIR and GHC_PKG_INPLACE: all the code that uses these
    should be turned off when $(STANDALONE_PACKAGE) is on.

  - GHC_INCLUDES: you shouldn't need this when $(STANDALONE_PACKAGE)
    is on.  For SRC_MKDEPENDC_OPTS, just don't add the -I flag, and
    similarly for the rules for building package.conf at the top
    of package.mk.

> 4) There also needs to be some changes so that you don't have
>     to refer to ../../mk
> 
>     At present, I work round it by executing the following commands.
> 
>     mkdir mk
>     (cd mk; ln -s ../../../mk/* .)
>     ln -s ../../aclocal.m4 .
>     ln -s ../../config.sub .
>     ln -s ../../config.guess .
>     ln -s ../../install-sh .

I don't get this.  Why do you need these links?

>     cp ../../configure.in configure.in
>     # comment out line 24 which reads:
>     # AC_CONFIG_SUBDIRS(ghc)

Does this cause an error for you when the ghc subdir is missing?  It
seems to work fine here, but perhaps you have a different autoconf
version (we have 2.13 on the machine I just tried it on).

>     autoconf
>     ./configure --with-greencard=/usr/bin/green-card 
> -with-ghc=/usr/bin/ghc
>     
>     make depend
>     make 
>     make install

That should be just 'make; make install'.  The rules in the top level
makefile arrange to run 'make boot', then 'make' for each project.

>     Note that I'm using the existing fptools configure.in 
> file with just
>    one line changed out of 1285 lines.  This file performs 
> far more checks 
>    than we need for most libraries but having just one file 
> to maintain
>    has an awful lot of advantages to counter this.

Yup, this should be more modular.

>    Ideally, those hacky symbolic links would be made a bit 
> more cleanly.
> 
>    The --with-greencard is required because it triggers 
> configure to look
>    for greencard and check that the version is >= 3.00.  If 
> you omit it,
>    greencard cannot be used.  (a bit ugly but I'm not sure 
> how to do it
>    better)
> 
>    I think the --with-ghc is only required because one of the 
> makefiles
>    refers to $(GHC) and I was too lazy to figure out whether 
> this could be
>    relaxed.

$(GHC) should default to whatever ghc is installed - the configure
script should detect it.  If it doesn't that's a bug.

> 5) FInally, the Makefile for the library can be much the same as those
>     in fptools/libraries except for three lines.
> 
>     TOP=.        # not TOP=..

Oh, I see now.  In that case you should probably copy the contents of
fptools/libraries/mk into fptools/<yourlibrary>/mk and that should avoid
the need for those symbolic links.  Except that you should have your own
version.mk (copy ghc/mk/version.mk and put appropriate settings in it),
and alter boilerplate.mk so it doesn't include GHC's version.mk.

This amounts to making your library into a fully-fledged "project" to
the build system.  Lots of things should Just Work when you do this -
such as building source & binary distributions.  Although the binary
distributions won't be too useful because there's no support for running
ghc-pkg at installation time (yet).

>   Also, we have to override the default libdir setting used in the
>   install rules.  Installing a library in /usr/lib is wrong - 
> they should
>   go in /usr/lib/ghc-5.04.2 (or wherever find-ghc-libdir reports).
> 
>      libdir=$(GHC_INSTALL_LIBDIR)

You *could* put libraries in the GHC install dir, but it might be
cleaner to put them in their own directories: /usr/lib/<yourlibrary>.
This *should* happen automatically if you set up the mk stuff as
described above.

> I'd like us to come up with a better plan for how to deal with 
> references to ghc/mk/paths.mk variables, figure out how
> to fix the libdir stuff, and then commit the above.

Does all that help?  We want a way to set $(STANDALONE_LIBRARY) - you
could set it yourself in fptools/<yourlibrary>/mk/boilerplate.mk, or it
could be dependent on whether fptools/ghc exists or not.

Cheers,
        Simon