From Marcus.Brinkmann@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@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@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
On Tue, Mar 19, 2002 at 11:17:55AM +0100, Joerg Schilling wrote:
From Marcus.Brinkmann@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.
You are putting this into my mouth. What I say is that i have never seen anyone in use, from my experience of porting 2000 Debian packages (and no, I don't know smake, as no Debian package, not even cdrtools, uses smale in its build process) that is better than the GNU tools. There might very well be better ones, and smake might be one of them. But it must be really good to convince me, as I think it is more important to use tools that developers are familiar with then do it differently 9eg there must be a real gain in doing it differently, so that it is worth changing or learning how to do it).
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.
Indeed. I have never ever seen a single byte of the Schily makefile system. I never said I had. I thought I was clear about it in my mail: When I am porting third party software, I port the Debian package because I have to do it anyway, and I am not doing a port twice, once for the upstream package and once for the Debian package. Sorry, it is a strange coincidence that the Debian package doesn't use the Schily makefile system. Maybe this should be fixed and it should use it. I don't know.
I am assuming here that the DEFAULT and RULES stuff is not the Schily makefile system. Because what the Debian package did at build time was definitely not based on automake or anything like that.
People who behave like you are called DAU in Germany. This is:
D�mmster Anzunehmender User (Silliest possible User).
Schnarch.
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.
Sorry, but I need it. In fact, as long as Debian does not use the Schily makefile system, I don't need that one at all. For third party packages (non GNU), I need exactly what is in Debian, nothing more and nothing less.
Are you saying that the build system in Debian has nothing to do with your software? Was it added by the Debian developer? I would be very surprised to learn that. Care to enlighten us about the nature of the stuff that s used by Debian to build the package?
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.
Maybe it was 30 bits. I don't remember it too well anymore. It was a problem that ruby was using one bit of the int for itself, so the effective bit length of int was reduced by one, which wasn't enough for us.
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 is nice to hear. The same can be said about the system used in most GNU packages. However, the Debian package does not use it.
Note that the reason I did not provide you feedback was because I knew that I did not try smake, and that you would not be interested in hearing about criticism of the non-smake build procedure. The only reason I followed up was that you mentioned it in reply to Jeroens mail.
I am very sorry that I don't have time to investigate your smake system right now (I don't have need for the features you mentioned). The dumbest user of the world is now going back to build the GNU system.
Thanks, Marcus
Marcus Brinkmann marcus@gnu.org wrote:
On Tue, Mar 19, 2002 at 11:17:55AM +0100, Joerg Schilling wrote:
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.
Maybe it was 30 bits. I don't remember it too well anymore. It was a problem that ruby was using one bit of the int for itself, so the effective bit length of int was reduced by one, which wasn't enough for us.
Yes, it was 30 bits. Ruby uses the least significant bit for marking an object as a Fixnum and the resulting number is still signed. The error codes of the Hurd need 31 bits (and are thus unsigned), because Mach uses some upper bits to encode error system and subsystem numbers in error values. But that was only one of many issues with Ruby on the Hurd, and while we have a Debian package thanks to Moritz' work, the upstream version doesn't compile yet.
Cheers, GNU/Wolfgang
I've now blocked all Joerg Schilling's mails on my accout. Couldn't everybody else please stop taking every flame bait lying around?
Thanx Joachim