GNU Hurd

[Joerg Schilling]

>From Marcus.Brinkmann at ruhr-uni-bochum.de Mon Mar 18 15:08:21 2002

I am sorry, but from reading your mail, I see no other way than writing
this answer to clear things up. You are:

Ignorant			-	Don't like to accept that there may be
					a better make system than the one you
					already lnow.

Learn resistant			-	You did not even read a single line
					of the README's and man pages in order
					to understand how the Schily makefile
					system works.

Spread lies on the Schily	-	See my comments below....
makefile system

People who behave like you are called DAU in Germany. This is:

Dümmster Anzunehmender User (Silliest possible User).


>I doesn't make sense for me to use smake because I am stuck with the Debian

The Debian packaging system has no relation to the Schily makefilesystem.
You definitely don't need this Debian system at all.

>packaging of cdrecord, which uses GNU make.  If you would use autoconf, or
>at least config.guess in your package, then I could have at least attempted
>to port any of the tools in the package.  But because you roll your own build
>system, which of course got confused about our uname output (we use
>something like i386-i386AT for the machine, and the dash seems to mess up
>your patterns), I could only spent some time trying to find out what KARCH,
>XARCH, whatever-ARCH are supposed to mean when I ran out of time.

The first lie!

The Schily makefilesystem _does_ use autoconf and config.guess
It uses enhanced versions of both tools because the original
distribution misses 50% of the needed tests or or includes missbehaving
tests.

If you like to compile on an unknown platform, you need to use smake because
you need automake features.

If you use GNU make you are limited by the fact that GNU make does not
include automake features. The UNAME output is irrelevant
as long as it follows the rules and use senseful values for the OS and
allow to distinguisch between different HW platforms for the OS.


>>From the point of view of someone who has fun writing their own build system
>it might be a clever thing to do, but let me tell you that with all the 2000
>source packages we compiled on the Hurd in the last three years, the most
>time consuming and annoying ones where those which did not use autoconf,
>automake, or, horror!, did not use GNU make (but pmake or imake or things
>like that), but provided their own clever system.  And of course, repeating
>all the wrong assumptions and bugs that I have already fixed in a dozen
>other, similarly broken build system written by likely-minded people who
>also thought it would be a clever idea and they could do better than
>the autoconf/automake maintainers.

Please stop rpeading just repeated lies. THe schily makefilesystem uses
autoconf, but it does not use automake because 

-	GNU automake is a step into the wrong direction.

-	GNU automake is _NOT_ a automake program but just a deprecated
	makefile generator.

>The setup like the one in cdrtools with all the mostly identical RULES/
>and DEFAULT/ files is the horror of my dreams.  This is because I spent lots
>of wasted hours in such systems, trying to understand what the hell this
>or that variable does exactly (btw, the worst package of this kind was still
>XFree86, which is a mix of everything and little documentation of the
>variables.  The best package of this sort is exim, which was quite easy to
>port because it is consequently feature based, and documents the variables).

How about reading manuals? The Schily make file system comes with
manual pages.


>I don't know your measure of triviality.  Certainly the port of XFree86 was
>non-trivial (see above).  The port of ruby was non-trivial (among others,
>because it assumes that errno fits into 31 bits).  The ruby maintainer gladly
>helped out here, although he probably doesn't use the Hurd himself.  The port
>of TeX was relatively trivial.

If errno does not fit into 31 bit, then it is broken because erno must be of 
type int ant here is no statement to allow errno to be negative.

The Schily makefile system is the most advanced make system I know.
It compiles without manual intervention on all supported and on many unknown 
platforms. It it the only system that I am aware of that implements something 
like the Slottable Source Plugin Module (SSPM) system which allows you to just
unpack and compile other sources inside a given source tree without needing
to edit anything. Just read README.SSPM and try it out with cdrtools as 
host tree and star or ved as SSPM versions.

Later versions will even allow you to e.g. kick in Lame into cdrtools
and make cdrtools use it without changing any line. This could have been 
implemented a year ago if I would have decided to drop SunPRO make support.

Jörg

 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling at fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix
 
 FOKUS at CeBIT Hall 11, A14 - BerliOS at CeBIT Hall 11 D11 (Future Market)
 
 Meet me at CeBIT in Hall 11 D11 on the BerliOS booth - www.berlios.de