Re: compiler framework, fortran, libtool, and other headaches

[Jon Buller <jon%bullers.net@localhost>]

Dan McMahill wrote:
> I recently added lang/gcc44 to pkgsrc with C, C++, OBJC, and FORTRAN 
> support.  Then I updated mk/compiler/gcc.mk accordingly.  I used the 
> entries for lang/gcc34 as an example in gcc.mk for what to do about gcc44.
>
> However, the more I have looked at this, the more problems I see.  I'm 
> wondering if I have just confused myself or if we have a more 
> fundamental problem we need to address.
>
> [snip]
>
> Comments?  Suggestions?

I had problems getting SBCL to build, and I see other packages like GHC
and SML (although I haven't looked at those in quite some time) have
similar bootstrapping problems.  I think my solution for SBCL might be
good to generalize, but I'm not sure of all the issues that might come
up, or the ones that would suddenly appear.

Anyway with SBCL, it's a simple problem: You need a Common Lisp system
to build it, but that is also what you are trying to build (perhaps for
the first time).  Ultra simple minded solution, depend on CLisp, but
CLisp couldn't cut it doing the build, and was at least twice as slow.

So I ended up making a directory on ftp.nb.o for prebuilt SBCL packages.
there is a directory tree for $MACHINE_ARCH and $OS_VERSION.  SBCL
then grabs one of those packages and untars it in $WRKDIR to get the
tools to build the package.  I think it's a bit more elegant than
lang/gcc3-ada just bailing if there is no ada compiler setup in the
Makefile variables.

I think this system might make building all native code compilers
simpler, and might cut the size of any bootstrap-pkgsrc bundles by
a significant amount.  And updating the binary tool package is simple
too, just pull a current working package out of a bulk build (or other
build) directory and drop it in the "native tool packages" directory.

I'd contemplate going into a bunch of the lang/ packages and doing
this conversion to them, but I have a limited set of machines to
work with, and my OS selection is about as limited.  Not to mention
that I don't know what surprises might be hidden in some of the more
used and popular language packages, along with odd interactions with
the build infrastructure itself...

Is that idea just just waiting for a return value of ESMOKEDCRACK?
Would it solve some of your problems, is it totally tangential, or
would it just make them worse?

Jon