Hello Craig,
* Craig Sanders wrote on Tue, Jun 19, 2007 at 07:39:11AM CEST:
>
> Thankyou for your prompt response to my two queries last week.
>
> I think I have solved my own problems. One of the problems was that I
> had defined the variable ;
>
> INSTALL = install -c -m 644
Above line is
* Behdad Esfahbod wrote on Tue, Jun 19, 2007 at 12:13:17AM CEST:
> On Sun, 2007-06-17 at 14:31 +0200, Ralf Wildenhues wrote:
>
> > If you can live with $(EXTRA_PROGRAMS) also
> > containing the tests, that is. If not, then I'd like to know why not.
>
> I can. But as a separate issue, I think a
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
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
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
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.
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)
#
* 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.
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
> 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
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'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
* 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
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:
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
* 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
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 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
19 matches
Mail list logo
