Ralf Wildenhues wrote:
Only if the source tree is read-only AND also the autotools ARE
present, then I can see how you get a failure.
That is my current situation, yes. Automake is present and the source
tree is read-only.
--rich
Ralf Wildenhues wrote:
What was your point again with respect to missing autotools?
Can you now finally be bothered to bring forward a specific setup that
goes wrong?
This fails for me because $(srcdir)/Makefile.in is read-only.
--rich
Harlan Stenn wrote:
And this situation is even more layered - I am using GNU AutoGen for one
big project, and I do not want to require my other developers to install
it. Therefore I check in my autogen-generated files and we use a
'bootstrap' script after doing a code checkout to make sure the
t
Ralf Wildenhues wrote:
What you seem to be saying is that anything that doesn't work with
automake is broken by definition.
No. What I'm asking for is a step-by-step reproducible example of the
breakage you are encountering, including the make implementation that
was used, and all other de
Harlan Stenn wrote:
I'll say it again - I am not interested in a reminder, I am interested
in being efficient at maintaining software packages. This means
*shortening* the development cycle.
Yes, this would seem to be the values set of automake. Shorten the
developer cycle at the cost of th
Harlan Stenn wrote:
I really dislike this proposal as it stands.
While I'm fine with a position that says "for normal users, don't have
Makefile.in depend on Makefile.am", I *want* that rule as a package
developer and even as a release engineer.
I already have way too much stuff I have to remem
Let me be very clear. The change I'm proposing is as follows. Instead
of the current form of generated Makefile.in's, I'm proposing that the
default generated Makefile.in's include a section like this:
Makefile: Makefile.in
configure etc.
.PHONY:
am_regen:
(cd $(srcdir) && automake)
#
Benoit Sigoure wrote:
Quoting "K. Richard Pixley" <[EMAIL PROTECTED]>:
Bob Proulx wrote:
If someone is trying to build from source control then they have
assumed the role of a developer.
No, I'm sorry, but that's not necessarily true. A developer of foo is
not nece
Ralf Wildenhues wrote:
Hello Richard,
* K. Richard Pixley wrote on Tue, Jun 19, 2007 at 05:18:27AM CEST:
AM_MAINTAINER_MODE is good to know about, thank you. But it doesn't really
solve the problem for users. Now if generated makefiles could have those
rules turned off using a co
Bob Friesenhahn wrote:
On Mon, 18 Jun 2007, K. Richard Pixley wrote:
Bob Proulx wrote:
Are we talking about one of your own projects? Or are we talking
about other projects that you are trying to build?
Projects that I'm trying to build. Hundreds of them. Projects that
won't b
use cases in mind).
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 anoth
Robert Collins wrote:
On Mon, 2007-06-18 at 17:27 -0700, K. Richard Pixley wrote:
My question today is... is there any hope of bringing automake
generated
Makefiles back into line with the GNU coding standards so that these
applications will work once again?
Use AM_MAINTAINER_MODE
Bob Proulx wrote:
K. Richard Pixley wrote:
I notice that automake is currently generating Makefiles that violate
the gnu coding conventions.
Hmm... I don't think that automake violates the standards. In the
normal case it is not required to have automake installed. Someone
w
I notice that automake is currently generating Makefiles that violate
the gnu coding conventions. Specifically, it's generating rules for
rebuilding "Makefile" from "Makefile.in" and "Makefile.in" from
"Makefile.am" which requires automake. And yet the gnu coding standards
specify:
The |
14 matches
Mail list logo
