* K. Richard Pixley wrote on Wed, Jun 20, 2007 at 08:21:55PM CEST:
> 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-o
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
* K. Richard Pixley wrote on Tue, Jun 19, 2007 at 11:00:49PM CEST:
> 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.i
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
* K. Richard Pixley wrote on Tue, Jun 19, 2007 at 09:46:10PM CEST:
>
> Pick a package that uses automake. Download the tarball. Unpack.
> Remove automake from your system.
>
> At this point we need to scramble the file time stamps. You can do this
> in any number of ways. The easiest, albe
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
* K. Richard Pixley wrote on Tue, Jun 19, 2007 at 09:21:53PM CEST:
> Harlan Stenn wrote:
> >I agree with Ralf - can you demonstrate an example of the problem you
> >are trying to solve?
> >
> I've already described the use case twice. And the response seems to be
> that automake doesn't support
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
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 remember to do, and adding
> 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
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
* K. Richard Pixley wrote on Tue, Jun 19, 2007 at 06:20:39PM CEST:
> Ralf Wildenhues wrote:
> >
> >If you have a counter example to above, please show how to reproduce it.
> >Thank you.
> >
> What you seem to be saying is that anything that doesn't work with
> automake is broken by definition.
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 necessarily a developer of bar.
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 command lin
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 necessarily a developer of bar. They may be capable of
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 command line and/or environment
On Mon, 18 Jun 2007, K. Richard Pixley wrote:
I'm on Ubuntu, not dos. It's source code control, (perforce, cvs,
subversion), that has a different idea of how time stamps should be handled
than automake does. It tends to think that the last mod time of a file
should be the time the file was la
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 be fixed in the
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 be
fixed in their current incarnation
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 be fixed in their current incarnations even if we correct automake
now. It'll tak
Are we talking about one of your own projects? Or are we talking
about other projects that you are trying to build?
K. Richard Pixley wrote:
> Bob Proulx wrote:
> > Someone who is simply building from the generated Makefiles never
> > needs to have automake installed. Only a developer who is
> >
"K. Richard Pixley" wrote:
> even be interested in regenerationg Makefile.in's automagically. As is,
> typical builders, (ie, not maintainers), are required to install
> automake in order to build packages requiring automake.
I think you're generalizing this to a degree that's not the case.
Mos
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 i
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
who is si
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
who is simply building from the ge
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 in your package; this wi
"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?
This is already supported, just add AM_MAINTAINER_MODE and the rules to
rebuild generat
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 |
31 matches
Mail list logo
