On Mon, Mar 18, 2002 at 09:41:34AM +0100, Joerg Schilling wrote:
From jeroen@dekkers.cx Sun Mar 17 14:13:56 2002
You are right: it _is_ important how fast bugs are fixed ;-)
Yes, that's why I fix the bugs myself if I can do so. I've the freedom to do so with Debian. You don't have that with Solaris. You depend on the willingness of some company. Poor you, that you've to wait a month for a simple bugfix.
Let me give a simple example to you that your assumption makes no sense in the real world:
There is a nasty bug in SunPRO make. If I would be able to fix it myself (I really am because it is easy to get Sun's sources) this would not help. It would force me to tell all users of my makefiles that they need to use my fix what many of them probably don't like (the same would happen with GNU make).
You see that while can introduce workarounds in my makefile system, it makes no sense to fix the program myself.
Do you want to know the way Debian works? You fix it yourself and tell the patch to the maintainer about it. The maintainer intergrates it and all users get the fix. As soon as the Debian maintainer intergrates the patch it's available in Debian unstable. Debian maintainers must forward patches upstream, so the upstream developers can intergrate it in the actual package and all users of the package gets the fix. This system works quite well. I think better than the SUN system.
Why should I spend my time on a badly written make program when I have my own make program that does what I like?
They don't complain about GNU make.
Because they only use a small fractioction of what makes sense to do with make.
I guess you never looked at the Hurd and glibc makefiles.
You did not understand how software development works....
You don't understand that you can't force volunteers to do something. If you want to see something, you've to do it yourself.
You don't understand that it does not make sense to to it yourself because the maintainers will not use your patches!
If you patch is right it won't be difficult to convince the maintainer if the maintainer isn't an asshole!!
I started to do this once with Linux and the /dev/sg* driver and I failed miserably because Alan Cox decided not to use my enhanced driver.
This is because Linux development sucks. And bitkeeper won't solve that. Now we're back to the original discussion.
So you found the proof that the persons envolved with GNU make don't even understand how to use make decently.
I never have problems with GNU make. Nor do the authors of GNU make or somebody else who wants to see it fixed. It works perfect, why should we change it? Because it doesn't work perfect for YOU? Then YOU should change it if you care about it. If you don't care about it, then happily use your own make.
It works perfect if you use a limited set of features.
It doesn't work if you try to use a feature which it does *NOT* have.
I am using documented feeatures because I need them, I tell people that they either may usev GNU make, but because of the GNU make bugs they should not complain before they were able to reproduce a problem using my smake.
Is the thing which doesn't work in GNU make a documented feature?
What is wrong with this way and why do you constantly tell people to do things that won't work in real world?
If it works for you, then stop complaining about the bugs in GNU make. I only tell that if you have problems with GNU make you should fix them yourself. If you want to use another piece of software, happily do so. Just don't promote non-free software on this list which goes about free software.
In fact the method shown in this mail is deprecated and the only method that works correctly is the method I use in the Schily makefile system. Ifg somebody believes that dependencies must not be put into platform dependant sub directories he simply did not understand how to create a po=
rtable
multi platform make system.
Look at glibc. It's portable, it uses GNU make and it works correctly.
The person was talking about the way to create dependency files and I can tell you that the only method that works reliable in a multi platform environment is the method used in the schily makefile system and the method promoted by the FSF people is deprecated because it will result in overwritten files in a multi-platform environment. Maybe if the GCC people learn to understand how to do it correctly inside GCC and there is no more old GCC outside I may switch to a better method for dependencies.
What do you mean with "multi-platform environment"? According to my experience developping glibc parts the build system works fine. If you have suggestions to improve it you're always welcome of course.
While GNU make does make the Makefile before using it (e.g. by retrieving it from SCCS) it does not make make files to be included even if there is=
a=20
rule.
And nobody with enough interest in GNU make needs this, so GNU make doesn't do it.
???
What's difficult to understand about this?
Sorry, I don't have much knowledge about companies and software who only like to restric me. Solaris might be free beer then, who cares.
Well the authors of GDB restrict me because it is the only debugger available on Linux and because I cannot do the things I expect a debugger to do.
Don't redefine restrict.
POSIX sucks more. It even contradicts itself. There are dozen of broken things in it.
This is often heard by people like you, but they are getting quiet when it comes to making concrete examples.
Those people aren't like me. Don't try to make me look bad before I have the chance to give an example.
If you have a system when there isn't a limit on the path and PATH_MAX doesn't exist, realpath() doesn't work correctly then. You've no way to be sure the buffer doesn't overflow, it's even a security risk.
AFAIK GNU tar makes POSIX compliant tars if you use the --posix option. I've done enough stuff with GNU tar, but GNU/Linux and GNU/Hurd are the only operating systems I use for real work.
Many GNU users have this wrong assumption, this is why I am more and more angry with the people who wrote documentation tha makes users believe untrue things about the GNU programs...
I hope you aren't in the group of people who just named and can give an example of the POSIX incompatible thing when using tar with the --posix option.
Jeroen Dekkers