* Neil Williams codeh...@debian.org schrieb:
Just as there are packages which cannot be automatically built just
from the VCS checkout and ./autogen.sh, hence the need for tarballs
where that work has already been done.
The interesting question is: why arent those packages buildable
directly
* Tollef Fog Heen tfh...@err.no schrieb:
]] Enrico Weigelt
| Autoconf (w/o automake) offers no means to tell additional m4
| include pathes (eg. in configure.ac), so that just calling
| autoreconf (w/o any additional parameters!) can do a full
| regeneration all on its own.
What's wrong
Simon McVittie s...@debian.org writes:
the convention is that autogen.sh *does* call ./configure
Huh? This is not my impression at all.
I'm sure there probably are packages out there where autogen.sh calls
configure, my general sense is that it usually doesn't.
Rather, autogen.m4 usually
]] Enrico Weigelt
| Autoconf (w/o automake) offers no means to tell additional m4
| include pathes (eg. in configure.ac), so that just calling
| autoreconf (w/o any additional parameters!) can do a full
| regeneration all on its own.
What's wrong with the suggestion in
Enrico Weigelt weig...@metux.de writes:
* Henrique de Moraes Holschuh h...@debian.org schrieb:
I'm (as upstream) using serval macros in their own .m4 files (eg.
in ./m4/, maybe even sorted into subdirs). Can autoreconf figure
out the required search pathes all on its own ?
The problem
* Simon McVittie s...@debian.org schrieb:
As much as I wish this had been the convention, it isn't - the convention is
that autogen.sh *does* call ./configure (often with options suitable for
developers of the project, whereas the ./configure defaults are more suitable
for packagers).
* Neil Williams codeh...@debian.org schrieb:
Which ones exactly (besides the usual autotools) ?
bison, flex and a few others.
Standard tools available on virtually any system that likes to
build anything ...
To make sure they're installed, use build-time dependencies. Done.
Also that
* Simon Josefsson si...@josefsson.org schrieb:
The problem is that autoreconf offers NO command line options for you to
pass the required -I parameters for aclocal, nor is there a way to encode
that information in the one place where it could conveniently live
(configure.ac) AFAIK.
* Enrico Weigelt weig...@metux.de [110508 21:45]:
Autoconf (w/o automake) offers no means to tell additional m4
include pathes (eg. in configure.ac), so that just calling
autoreconf (w/o any additional parameters!) can do a full
regeneration all on its own.
Given that aclocal is part of
* Neil Williams codeh...@debian.org schrieb:
./autogen.sh does not clean anything.
Clarification: with clean state I meant a state of the tree
where all the generated files (from autotools+friends) have been
reliably regenerated afresh (no leftovers from previous runs).
Removing temporary
* Neil Williams codeh...@debian.org schrieb:
(forgot attachments)
...
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq:
* Bernhard R. Link brl...@debian.org schrieb:
Given that aclocal is part of automake that is not very surprising.
If you want to use it without automake, you could just add a single-line
Makefile.am with the needed data (without AM_INIT_AUTOMAKE in configure.ac
autoreconf will not call
On Sun, 8 May 2011 22:36:20 +0200
Enrico Weigelt weig...@metux.de wrote:
The options are just passed on unchanged. No problem with that. Can
still call ./configure directly. Maybe it wastes a little bit of time
but if you're cross-building, you're using a really fast machine so
this is
* Josue Abarca jmasli...@debian.org.gt schrieb:
From: /usr/share/doc/autotools-dev/README.Debian.gz
Example autogen.sh and debian/rules files can be found in
/usr/share/doc/autotools-dev/examples. Do not use them as-is. Rather,
properly customize your own.
and from
* Neil Williams codeh...@debian.org schrieb:
Not every generated file needs to be cleaned. The list can vary if the
package is very old and depends on how the package itself handles the
clean internally.
IMHO, *all* generated files should be cleaned away, just to be sure.
In the last decade
* Henrique de Moraes Holschuh h...@debian.org schrieb:
1. No spawn from autotooling allowed in the VCS. EVER. .gitignore it
away at once. Autogenerated files inside the VCS repo are almost
always a bad idea. It was madness with CVS, it was bad mojo with
SVN, and it is certainly
On Sat, 7 May 2011 13:48:00 +0200
Enrico Weigelt weig...@metux.de wrote:
* Neil Williams codeh...@debian.org schrieb:
Not every generated file needs to be cleaned. The list can vary if the
package is very old and depends on how the package itself handles the
clean internally.
IMHO,
* Henrique de Moraes Holschuh h...@debian.org schrieb:
Yes. I think it was Cyrus IMAP that required -I in places where
autoreconf doesn't reach, so I called each tool separately. Which is
obviously a problem in autoreconf.
Is it really a problem of autoreconf ?
Imagine the following
On Sat, 7 May 2011 13:33:53 +0200
Enrico Weigelt weig...@metux.de wrote:
* Josue Abarca jmasli...@debian.org.gt schrieb:
From: /usr/share/doc/autotools-dev/README.Debian.gz
Example autogen.sh and debian/rules files can be found in
/usr/share/doc/autotools-dev/examples. Do not use them
* Neil Williams codeh...@debian.org schrieb:
No. Reverting the build to the point where it is equivalent to only
what is in the VCS adds completely unnecessary build dependencies and
build stages.
Which ones exactly (besides the usual autotools) ?
VCS is not the final source, it's a tool
* Sean Finney sean...@debian.org schrieb:
big_snip /
IOW: all the fun of indeterministically self-modifying code ...
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email:
On Sat, 7 May 2011 15:41:22 +0200
Enrico Weigelt weig...@metux.de wrote:
* Neil Williams codeh...@debian.org schrieb:
No. Reverting the build to the point where it is equivalent to only
what is in the VCS adds completely unnecessary build dependencies and
build stages.
Which ones
* Neil Williams codeh...@debian.org schrieb:
Nonsense. It is not the job of ./autogen.sh to revert to the VCS state
It is it's job to produce a clean state where *all* generated
files have been regenerated and the next stage (configure)
can start from here, w/o any manual intervention or
On Sat, 7 May 2011 16:51:01 +0200
Enrico Weigelt weig...@metux.de wrote:
* Neil Williams codeh...@debian.org schrieb:
Nonsense. It is not the job of ./autogen.sh to revert to the VCS state
It is it's job to produce a clean state where *all* generated
files have been regenerated and the
On Sat, 07 May 2011, Enrico Weigelt wrote:
* Henrique de Moraes Holschuh h...@debian.org schrieb:
Yes. I think it was Cyrus IMAP that required -I in places where
autoreconf doesn't reach, so I called each tool separately. Which is
obviously a problem in autoreconf.
Is it really a
]] Henrique de Moraes Holschuh
Hiya,
| The problem is that autoreconf offers NO command line options for you to
| pass the required -I parameters for aclocal, nor is there a way to encode
| that information in the one place where it could conveniently live
| (configure.ac) AFAIK.
Can't you use
* Henrique de Moraes Holschuh h...@debian.org schrieb:
I'm (as upstream) using serval macros in their own .m4 files (eg.
in ./m4/, maybe even sorted into subdirs). Can autoreconf figure
out the required search pathes all on its own ?
The problem is that autoreconf offers NO command line
On Sat, 07 May 2011 at 13:33:53 +0200, Enrico Weigelt wrote:
c) does _NOT_ call configure
As much as I wish this had been the convention, it isn't - the convention is
that autogen.sh *does* call ./configure (often with options suitable for
developers of the project, whereas the ./configure
On Sat, 07 May 2011, Tollef Fog Heen wrote:
| The problem is that autoreconf offers NO command line options for you to
| pass the required -I parameters for aclocal, nor is there a way to encode
| that information in the one place where it could conveniently live
| (configure.ac) AFAIK.
Marcin Owsiany porri...@debian.org writes:
On Tue, Mar 15, 2011 at 10:29:57PM +, Marcin Owsiany wrote:
How are others doing it?
Thanks for all the responses (I never expected to start such a big
discussion - it must have been a while since I last read debian-devel),
and especially for
Hi,
On Fri, Mar 18, 2011 at 02:40:41PM +0100, Goswin von Brederlow wrote:
Marcin Owsiany porri...@debian.org writes:
On Tue, Mar 15, 2011 at 10:29:57PM +, Marcin Owsiany wrote:
How are others doing it?
Thanks for all the responses (I never expected to start such a big
discussion
On Thu, Mar 17, 2011 at 11:21:52AM +0800, Paul Wise wrote:
5. Cheerfully ignore any purists complaining that debian/rules clean does
not restore whatever crap was there upstream.
I generally don't bother with these unless I'm patching the autotools
source files
On Thu, Mar 17, 2011 at 3:15 PM, Andreas Tille andr...@an3as.eu wrote:
Would you consider the existence of autotools autogenerated files inside
an upstream source a valid reason to rebuild upstream source in a
get-orig-source target?
I would consider autotools generated files (Makefile.in,
On Wed, 2011-03-16 at 16:36 +, Ian Jackson wrote:
Then, you need a way to patch them. There is lots of software where
you need to patch configure.ac and/or Makefile.am
That's fine, you patch the input, rerun the autofoobar stuff, and then
build the source package with diff. If you're
On Thu, 17 Mar 2011, Sean Finney wrote:
If you do it with the patch system (quilt or even plain dpkg),
before building the package source, you cannot ensure that files are
patched in the right order.
What do you mean in the right order ?
autofoo stuff examines timestamps on
On Thu, Mar 17, 2011 at 03:32:05PM +0800, Paul Wise wrote:
On Thu, Mar 17, 2011 at 3:15 PM, Andreas Tille andr...@an3as.eu wrote:
Would you consider the existence of autotools autogenerated files inside
an upstream source a valid reason to rebuild upstream source in a
get-orig-source
On Thu, Mar 17, 2011 at 4:02 PM, Andreas Tille andr...@an3as.eu wrote:
Sorry, I was not precise. I also regard Makefile.in and configure (and
files which are used by configure to run properly) as useful in an
upstream tarball. However, files like config.log etc. should be cleaned
up.
Am 17.03.2011 08:51, schrieb Sean Finney:
So Makefile rules can then re-run auto* tools at build time and you
lost the benefit you want to have.
Makefile rules should not rerun auto* stuff at build time.
they will if AM_MAINTAINER_MODE is being used, in some cases.
It's really the other
On Thu, Mar 17, 2011 at 04:09:25PM +0800, Paul Wise wrote:
Agreed. That would usually not be something that would cause enough
problems for a new tar.gz to be warranted though.
I just accept your opinion that repackaging is not warranted and I did
not in the past - but I was never really sure
On Thu, Mar 17, 2011 at 4:34 PM, Andreas Tille andr...@an3as.eu wrote:
I just accept your opinion that repackaging is not warranted and I did
not in the past - but I was never really sure whether this is really
reasonable. I'm somehow missing *clear* rules when to rebuild the orig
tarball
On Thu, Mar 17, 2011 at 04:40:29PM +0800, Paul Wise wrote:
My rule is: when there is something non-free or when the amount of
useless stuff is huge. For example I would repack a tarball with a
small program and 20Mb of embedded code copies of all its dependencies
to remove the deps.
What
On to, 2011-03-17 at 10:12 +0100, Andreas Tille wrote:
On Thu, Mar 17, 2011 at 04:40:29PM +0800, Paul Wise wrote:
My rule is: when there is something non-free or when the amount of
useless stuff is huge. For example I would repack a tarball with a
small program and 20Mb of embedded code
On Thu, Mar 17, 2011 at 09:17:27AM +, Lars Wirzenius wrote:
My rule is: when there is something non-free or when the amount of
useless stuff is huge. For example I would repack a tarball with a
small program and 20Mb of embedded code copies of all its dependencies
to remove the
On Thu, Mar 17, 2011 at 5:12 PM, Andreas Tille andr...@an3as.eu wrote:
The problem is that the regenerated files are not identical to the
original files and you simply get a diff which finally makes different
Debian source packages depending how often you start the build process.
You won't
On Thu, Mar 17, 2011 at 10:12:35 +0100, Andreas Tille wrote:
On Thu, Mar 17, 2011 at 04:40:29PM +0800, Paul Wise wrote:
Eh? Rebuilding twice in a row would remove the files, regenerate them,
remove them, regenerate them. I can't see how the second regeneration
would fail if the first one
On Thu, Mar 17, 2011 at 09:17:05AM +0100, Michael Biebl wrote:
Am 17.03.2011 08:51, schrieb Sean Finney:
So Makefile rules can then re-run auto* tools at build time and you
lost the benefit you want to have.
Makefile rules should not rerun auto* stuff at build time.
they will if
On Thu, Mar 17, 2011 at 10:30:48AM +0100, Julien Cristau wrote:
The problem is that the regenerated files are not identical to the
original files and you simply get a diff which finally makes different
Debian source packages depending how often you start the build process.
Err, no. If
Sean Finney writes (Re: Best practice for cleaning autotools-generated
files?):
On Wed, 2011-03-16 at 16:36 +, Ian Jackson wrote:
That's fine, you patch the input, rerun the autofoobar stuff, and then
build the source package with diff. If you're using a patch queue
system, or a vcs
On Thu, 17 Mar 2011, Paul Wise wrote:
Does your autogen.sh script ever become anything more than calling
autoreconf with some specific options?
Yes. I think it was Cyrus IMAP that required -I in places where
autoreconf doesn't reach, so I called each tool separately. Which is
obviously a
On Thu, 17 Mar 2011, Andreas Tille wrote:
On Thu, Mar 17, 2011 at 04:09:25PM +0800, Paul Wise wrote:
Agreed. That would usually not be something that would cause enough
problems for a new tar.gz to be warranted though.
I just accept your opinion that repackaging is not warranted and I did
On Thu, 17 Mar 2011, Andreas Tille wrote:
Assume please the following:
1. Unpack upstream source, copy debian/ dir into it
2. make -f debian/rules clean
You should have looked for a get-orig-sources target, first. You just
skipped any orig source conditioning the maintainer had to do.
On Thu, 17 Mar 2011, Sean Finney wrote:
autofoo stuff examines timestamps on various files, so it's possible
that if configure gets patched before configure.ac, and
AM_MAINTAINER_MODE is set to a specific value, that ./configure ends up
wanting to regenerate ./configure at build time. double
On Thu, Mar 17, 2011 at 11:01:44AM -0300, Henrique de Moraes Holschuh wrote:
On Thu, 17 Mar 2011, Andreas Tille wrote:
Assume please the following:
1. Unpack upstream source, copy debian/ dir into it
2. make -f debian/rules clean
You should have looked for a get-orig-sources
Adam Borowski writes (Re: Best practice for cleaning autotools-generated
files?):
Ie, consistently with all regular commands in a makefile: if a source file
has been modified, everything that is generated from that source needs to be
rebuilt.
Which works just fine if timestamps haven't been
]] Ian Jackson
Hi,
| Adam Borowski writes (Re: Best practice for cleaning autotools-generated
files?):
| Ie, consistently with all regular commands in a makefile: if a source file
| has been modified, everything that is generated from that source needs to be
| rebuilt.
|
| Which works
[Bernhard R. Link]
It usually also make sense to think twice before patching build
systems. Especially automake is very good in allowing many things
changed without having to patch something. (There are some cases
where patches are necessary, but there are also enough cases where
patching
Peter Samuelson writes (Re: Best practice for cleaning autotools-generated
files?):
Better to take on this risk, such as it is, by building from source
every time. It's the only way to know we _can_. And fix whatever
issues come up. Even though it's not actually spelled out in the DFSG,
I
* Peter Samuelson pe...@p12n.org [110317 19:12]:
If there _is_ some risk or perception of risk, that re-auto-tooling a
package might break it, then we're not really providing the FSF's
freedom 1. We're then saying This is free software; downstream users
can modify the .c files, you can modify
Tollef Fog Heen writes (Re: Best practice for cleaning autotools-generated
files?):
| Adam Borowski writes (Re: Best practice for cleaning autotools-generated
files?):
| No, it doesn't work if the auto* on the system is not compatible with
| the auto* in the package, which happens very often
Ian Jackson ijack...@chiark.greenend.org.uk writes:
The design of autoconf is predicated on the idea that people who are
building the package are given a portable configure as part of the
source package, so there is no need to have good compatibility between
configure.in and various versions
On Tue, Mar 15, 2011 at 10:29:57PM +, Marcin Owsiany wrote:
How are others doing it?
Thanks for all the responses (I never expected to start such a big
discussion - it must have been a while since I last read debian-devel),
and especially for the pointer to dh-autoreconf. This looks like
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2011-03-15 23:55, Neil Williams wrote:
Using autotools with Debian native packages can be a real PITA and
source format 3.0 just gets it wrong mostly. Most other tools also get
it wrong, even svn-buildpackage. If I knew how to fix it reliably
On Tue, Mar 15, 2011 at 10:29:57PM +, Marcin Owsiany wrote:
* maintain a whitelist of distributed files, and rm everything
else (apart from the debian directory) in the clean target.
Since I use (or plan to use) git-buildpackage, I don't have a tarball
which could serve as an
On Tue, 15 Mar 2011 23:35:59 +
Ben Hutchings b...@decadent.org.uk wrote:
On Tue, Mar 15, 2011 at 10:55:54PM +, Neil Williams wrote:
Other tools, like svn-buildpackage, don't have this problem, via the
mergeWithUpstream support and/or a ../tarballs/ directory. Not perfect
but it
* Marcin Owsiany porri...@debian.org [110315 23:30]:
The current best practice for dealing with packages using GNU autotools
(as described in /usr/share/doc/autotools-dev/README.Debian.gz) is to
run autoreconf in a prerequisite of a build target, and to remove its
results in the clean target.
Marcin Owsiany writes (Best practice for cleaning autotools-generated files?):
The current best practice for dealing with packages using GNU autotools
(as described in /usr/share/doc/autotools-dev/README.Debian.gz) is to
run autoreconf in a prerequisite of a build target, and to remove its
On 16/03/2011 14:59, Ian Jackson wrote:
Marcin Owsiany writes (Best practice for cleaning autotools-generated
files?):
The current best practice for dealing with packages using GNU autotools
(as described in /usr/share/doc/autotools-dev/README.Debian.gz) is to
run autoreconf
On Tue, Mar 15, 2011 at 10:29:57PM +, Marcin Owsiany wrote:
The current best practice for dealing with packages using GNU autotools
(as described in /usr/share/doc/autotools-dev/README.Debian.gz) is to
run autoreconf in a prerequisite of a build target, and to remove its
results in the
* Vincent Danjean vdanjean...@free.fr [110316 15:48]:
Then, you need a way to patch them. There is lots of software where
you need to patch configure.ac and/or Makefile.am
Having to patch something and having to patch nothing are two very
different cases.
It usually also make sense to think
Vincent Danjean writes (Re: Best practice for cleaning autotools-generated
files?):
On 16/03/2011 14:59, Ian Jackson wrote:
I think this is bad advice. These files should be shipped in the
source package.
Doing that makes it much easier to build the package in unexpected
Am 16.03.2011 17:36, schrieb Ian Jackson:
Vincent Danjean writes (Re: Best practice for cleaning autotools-generated
files?):
So Makefile rules can then re-run auto* tools at build time and you
lost the benefit you want to have.
Makefile rules should not rerun auto* stuff at build time
On Tue, 15 Mar 2011, Josue Abarca wrote:
What about?:
From: /usr/share/doc/autotools-dev/README.Debian.gz
Example autogen.sh and debian/rules files can be found in
/usr/share/doc/autotools-dev/examples. Do not use them as-is. Rather,
properly customize your own.
And look at the dates of
On Wed, 16 Mar 2011, Neil Williams wrote:
On Tue, 15 Mar 2011 23:35:59 +
Ben Hutchings b...@decadent.org.uk wrote:
On Tue, Mar 15, 2011 at 10:55:54PM +, Neil Williams wrote:
Other tools, like svn-buildpackage, don't have this problem, via the
mergeWithUpstream support and/or a
On Thu, Mar 17, 2011 at 3:35 AM, Henrique de Moraes Holschuh
h...@debian.org wrote:
Well, I have been doing this, for a LONG time, to preserve my sanity when
working as upstream or in a native auto-tooled package:
1. No spawn from autotooling allowed in the VCS. EVER. .gitignore it
away
Hello,
The current best practice for dealing with packages using GNU autotools
(as described in /usr/share/doc/autotools-dev/README.Debian.gz) is to
run autoreconf in a prerequisite of a build target, and to remove its
results in the clean target.
However that README does not give any hints on
Dear Marcin,
Marcin Owsiany schrieb am 15.03.2011 23:29:
However that README does not give any hints on how to best do the
cleaning. How are others doing it?
in puf we're using dh-autoreconf in the dh(7) sequence, which creates a list of
modified files, backs them up and restores them later
On Tue, Mar 15, 2011 at 10:29:57PM +, Marcin Owsiany wrote:
Hello,
The current best practice for dealing with packages using GNU autotools
(as described in /usr/share/doc/autotools-dev/README.Debian.gz) is to
run autoreconf in a prerequisite of a build target, and to remove its
results
On Tue, 15 Mar 2011 22:29:57 +
Marcin Owsiany porri...@debian.org wrote:
The current best practice for dealing with packages using GNU
autotools (as described
in /usr/share/doc/autotools-dev/README.Debian.gz) is to run
autoreconf in a prerequisite of a build target, and to remove its
On 15/03/11 22:29, Marcin Owsiany wrote:
The current best practice for dealing with packages using GNU autotools
(as described in /usr/share/doc/autotools-dev/README.Debian.gz) is to
run autoreconf in a prerequisite of a build target, and to remove its
results in the clean target.
However
On Tue, Mar 15, 2011 at 10:55:54PM +, Neil Williams wrote:
On Tue, 15 Mar 2011 22:29:57 +
Marcin Owsiany porri...@debian.org wrote:
[...]
Since I use (or plan to use) git-buildpackage, I don't have a
tarball which could serve as an authoritative whitelist. Thus an
additional
80 matches
Mail list logo
