|
From: | K. Richard Pixley |
Subject: | Re: Automake violations of the gnu coding conventions |
Date: | Mon, 18 Jun 2007 22:35:24 -0700 |
User-agent: | Thunderbird 2.0.0.4 (Macintosh/20070604) |
Bob Proulx wrote:
Projects that I'm trying to build. Hundreds of them. Projects that won't be fixed in their current incarnations even if we correct automake now. It'll take years, maybe decades for this change to propagate into all of the packages that suffer from this problem today. I know that. And I'm willing to help with that effort if it's deemed appropriate to return to the GNU coding standards, (which were formulated with these use cases in mind).Are we talking about one of your own projects? Or are we talking about other projects that you are trying to build?
I will be solving this problem somehow. The real question is whether we can cooperate in such a way that we solve it once now and everyone can benefit, or whether I'm going to solve it today for this company, tomorrow for some other company, and next week for yet another company.
That's really not a helpful or useful attitude. I can also reasonably avoid any of these problems by avoiding any program that uses automake. Avoiding the problem isn't really solving it.K. Richard Pixley wrote:Bob Proulx wrote:But that's my point. With the defaults as they are now there are many "normal" cases where automake is required.Someone who is simply building from the generated Makefiles never needs to have automake installed. Only a developer who is modifying the automake source files would need automake installed.But the cases that you have described so far are not normal cases. They all entail doing something that can be reasonably avoided.
Of course these aren't the common, current automake use cases. Automake can't solve these cases now and thus these cases can't be covered. What I'm talking about is extending automake to cover the cases that used to be possible prior to automake.
Fine, then. rsync. Or cvs, or subversion, or perforce. There are many situations where source can be transmitted which do not preserve file modification times. And I really don't think that the rest of the world should be modified solely to support this deficit of automake. Especially not when the solution is so simple - just follow the gnu coding standards.I have already done so. The actual use case is somewhat more involved than is necessary to explain the problem.Obviously from the questions you are asking you are experiencing a specific problem. Could you share some details?Reading your mail carefully I note you say that 'cp' does not retain file timestamps. Instead of using 'cp -r' use 'cp -a' to preserve the timestamps. An easy problem to avoid. Or "correct" them later by updating all of the timestamps. Either works.
No, I'm sorry, but that's not necessarily true. A developer of foo is not necessarily a developer of bar. They may be capable of becoming one, but that's not how most organizations prefer to allocate their talent.If someone is trying to build from source control then they have assumed the role of a developer.
Actually, it's not. At this point in time, to build a variety of free software, (say, debian), requires multiple versions of multiple autofoo tools.Developers are expected to have the required development tools available. Almost certainly in the case of checking out pristine source from version control many developer tools will be needed for most projects. This goes beyond automake and includes gettext, flex, bison, gperf, texinfo, etc.
Consider the use case where a third party is both collecting released code as well as monitoring it locally. There may or may not be local changes to that code prior to further releases. And it may or may not be possible to regenerate the generated files what with ancient code, version incompatibilities between the autofoo packages, etc. In this case it is necessary to track both the original source as well as the generated files. And to return the generated files back to the GNU coding standards in order to keep them building.
A much more efficient approach involves using the generated files as they were released. But unfortunately, this isn't really feasible with the Makefile -> Makefile.in -> Makefile.am rules as they come now.
--rich
[Prev in Thread] | Current Thread | [Next in Thread] |