Re: Autoreconfing guide

[Henrique de Moraes Holschuh]

On Fri, 18 Jul 2014, Russ Allbery wrote:
> Henrique de Moraes Holschuh  writes:
> > Indeed.  In most cases, there will be a shell script somewhere (one of
> > the usual names is "autogen.sh") that will call autoreconf with the
> > appropriate options.
> 
> Be careful of those scripts.  Often they do other things that you don't
> actually want done, and they don't always regenerate everything.

True.  At some point you have no choice but to either pester upstream, or
document in README.source the stuff that needs to be verified manually at
every new upstream release :-(

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140718231753.gb14...@khazad-dum.debian.net

Re: Autoreconfing guide

[Wookey]

+++ Henrique de Moraes Holschuh [2014-07-18 19:55 -0300]:
> On Fri, 18 Jul 2014, Wookey wrote:
> > +++ Russ Allbery [2014-07-15 23:55 -0700]:
> > > Yavor Doganov  writes:
> > > 
> > > > I also wonder why debian/autoreconf is needed given that autoreconf
> > > > is recursive.
> > > 
> > > I don't think autoreconf can always figure out what to do when the files
> > > are buried in some random subdirectory without anything at the top level.
> > 
> > Correct. It's generally when the source is in a subdir and there is
> > nothing autotooly at all at the top level. Or when the package
> > effectively contains two separate autoconf source trees in it.
> 
> Indeed.  In most cases, there will be a shell script somewhere (one of the
> usual names is "autogen.sh") that will call autoreconf with the appropriate
> options.
> 
> > level. I don't know if it's possible to explain this layout to
> > autotools, or if it's just something we should be telling upstream to
> > stop doing? (I've been dealing with it by backing-up
> 
> Well, as long as there is an "autogen.sh"-style script somewhere in the
> build tree that does this...
> 
> We ought to document locating and using these autogen scripts as a preferred
> substitute to running autoreconf directly (this assumes upstream does use
> the autogen script :-p).  There is no way to automate adding this to the
> package, you have to customize debian/rules in a case-by-case basis, though.

I'd like to have some info on when to use an upstream autogen.sh vs
autoreconfing (possibly with options). The one instance I've seen of a
package where the maintainer used the upstream-supplied autogen.sh
didn't work well at all (FTBFS on new arches), whilst autoreconfing
_and_ dh-autotools-deving worked fine. That was libgc which was an
interesting case:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732349
and most relevantly:
https://lists.debian.org/debian-devel/2014/04/msg00459.html

I forget exactly why the autogen.sh in that package wasn't
sufficient/correct, but my understanding is that autogen.sh is usually
designed to set up the package for a developer to build from a fresh
VCS checkout, which may not be quite the same as setting up a released
'tarball' to build on the current system. ('maintainer mode',
etc). But my understanding is vague here.

This is all the stuff that needs writing down in comprehensible form
for baffled maintainers.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140718231628.gm22...@stoneboat.aleph1.co.uk

Re: Autoreconfing guide

[Russ Allbery]

Henrique de Moraes Holschuh  writes:

> Indeed.  In most cases, there will be a shell script somewhere (one of
> the usual names is "autogen.sh") that will call autoreconf with the
> appropriate options.

Be careful of those scripts.  Often they do other things that you don't
actually want done, and they don't always regenerate everything.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87y4vq9smm@windlord.stanford.edu

Re: Autoreconfing guide

[Henrique de Moraes Holschuh]

On Fri, 18 Jul 2014, Wookey wrote:
> +++ Russ Allbery [2014-07-15 23:55 -0700]:
> > Yavor Doganov  writes:
> > 
> > > I also wonder why debian/autoreconf is needed given that autoreconf
> > > is recursive.
> > 
> > I don't think autoreconf can always figure out what to do when the files
> > are buried in some random subdirectory without anything at the top level.
> 
> Correct. It's generally when the source is in a subdir and there is
> nothing autotooly at all at the top level. Or when the package
> effectively contains two separate autoconf source trees in it.

Indeed.  In most cases, there will be a shell script somewhere (one of the
usual names is "autogen.sh") that will call autoreconf with the appropriate
options.

> level. I don't know if it's possible to explain this layout to
> autotools, or if it's just something we should be telling upstream to
> stop doing? (I've been dealing with it by backing-up

Well, as long as there is an "autogen.sh"-style script somewhere in the
build tree that does this...

We ought to document locating and using these autogen scripts as a preferred
substitute to running autoreconf directly (this assumes upstream does use
the autogen script :-p).  There is no way to automate adding this to the
package, you have to customize debian/rules in a case-by-case basis, though.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140718225529.ga14...@khazad-dum.debian.net

Re: Autoreconfing guide

[Yavor Doganov]

Wookey wrote:
> +++ Russ Allbery [2014-07-15 23:55 -0700]:
> > I don't think autoreconf can always figure out what to do when the
> > files are buried in some random subdirectory without anything at
> > the top level.
> 
> Correct. It's generally when the source is in a subdir and there is
> nothing autotooly at all at the top level.

Sure, but the wiki page leaves the impression that you must add
debian/autoreconf in almost all cases, it says "plain dh_autoreconf
will often not work".  Such cases should be relevantly rare, I think,
as most packages have a top-level configure and use AC_CONFIG_SUBDIRS.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87bnsmib7o.GNUs_not_UNIX!%ya...@gnu.org

Re: Autoreconfing guide

[Wookey]

+++ Russ Allbery [2014-07-15 23:55 -0700]:
> Yavor Doganov  writes:
> 
> > I also wonder why debian/autoreconf is needed given that autoreconf
> > is recursive.
> 
> I don't think autoreconf can always figure out what to do when the files
> are buried in some random subdirectory without anything at the top level.

Correct. It's generally when the source is in a subdir and there is
nothing autotooly at all at the top level. Or when the package
effectively contains two separate autoconf source trees in it.

It's not very common but certainly have some of these. 

There are also packages that put all the auto* files, including
configure.ac, in a subdir, but put configure itself at the top
level. I don't know if it's possible to explain this layout to
autotools, or if it's just something we should be telling upstream to
stop doing? (I've been dealing with it by backing-up
the top-level configure, running autoconf in the subdir, copying the
resulting configure up to the top, and building. Then put the old,
shipped, configure back manually on clean. Which is just ugly).

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140718212059.gi22...@stoneboat.aleph1.co.uk

Re: Autoreconfing guide

[Russ Allbery]

Yavor Doganov  writes:

> Probably you're right; I guess this is due to the misarable experience I
> had in the past, with Gtk+/GNOME packages in particular.  Even now if I
> look at the packages I maintain, they're full of underquoted and
> obsolete macros.  These things are fixable, as you say, but some
> upstream maintainers are very reluctant to incorporate changes to the
> build system.  I have seen my proper m4 quotation deliberately removed
> and classified as "obfuscation".  In this age, some people still use
> AC_TRY_* macros in new packages because that is what they copy/pasted
> eons ago.

Yes, you're not wrong.  I suppose the caveat I should attach to my
experience is that I'm a fairly experienced Autoconf user (dating back to
the version 1 days, in fact, although I only started using it in earnest
with version 2), so while writing detailed m4 macros is usually beyond me,
I can fairly easily debug and fix most Autoconf scripts.  People with less
experience will be less comfortable being aggressive about this.

I do wish that more maintainers would treat Autoconf with the same care
that they would treat, say, their C or Perl or Python coding style and
stay similarly current in the language.  It's not that hard to go through
the changelog of new Autoconf releases and adjust for new recommended
macros.  But if you don't do it regularly, the accumulated work becomes
intimidating.

> What about packages that use a custom bootstrap script and/or gnulib?
> Should gnulib be updated too?

I would not update gnulib.

A good case can be made to do this, but, as you say, it's dangerous.  The
huge difference with gnulib vs. Autoconf and Automake is that the latter
don't contain any code that actually makes it into the final binaries.
You can get some weird bugs, but by and large the software just doesn't
build, or, worst case, builds with the wrong libraries.  Updating gnulib
can violate the expectations of the actual code, and possibly even
introduce security vulnerabilities.  That's a lot trickier.

Most of gnulib *should* be inactive on a current glibc system, although I
know that's not always the case.

> What about packages which have AC_PREREQ for an Autoconf version that is
> not yet packaged for Debian, or depend on a new Automake version/feature
> (a minor issue, but it has happened in the past)?

This used to be quite common, but honestly I've not seen it in years.  A
lot of the concerns that people have about always running autoreconf were
completely valid and correct five years ago or so, but they've gotten a
lot more stable (in part because upstream development of the projects has
died down a bit again).

> I also wonder why debian/autoreconf is needed given that autoreconf
> is recursive.

I don't think autoreconf can always figure out what to do when the files
are buried in some random subdirectory without anything at the top level.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zjg9g5ci@windlord.stanford.edu

Re: Autoreconfing guide

[Yavor Doganov]

Russ Allbery wrote:
> Yavor Doganov  writes:
> > However, this is not how the GNU build system is intended to be used.
> 
> Meh.  I think this is a non-issue.

I didn't mean it is an issue in that sense.  Such usage will reveal
unexpected bugs, that's all.  It may be even welcomed by some of the
upstream GNU autotools maintainers as that will reveal bugs in their
code, too.

Some of these bugs may be hard to spot (for example, miscompilation or
misbehaviour of a particular test as opposed to FTBFS) and may sneak
into stable releases.

I won't comment on the points you raise because they are valid if you
consider Autoconf a shell compiler (which it is, in a sense) and
Automake a makefile generator.

> I find your concerns excessively alarmist.

Probably you're right; I guess this is due to the misarable experience
I had in the past, with Gtk+/GNOME packages in particular.  Even now
if I look at the packages I maintain, they're full of underquoted and
obsolete macros.  These things are fixable, as you say, but some
upstream maintainers are very reluctant to incorporate changes to the
build system.  I have seen my proper m4 quotation deliberately removed
and classified as "obfuscation".  In this age, some people still use
AC_TRY_* macros in new packages because that is what they copy/pasted
eons ago.

> I have been rebuilding all the Autoconf and Automake files from
> scratch for all packages I maintain for quite some time now,
> including some very complex packages and packages with a mess of
> Autoconf macros, and have had few problems

For a well maintained build system that follows the recommended
practices autoreconf-ing is unlikely to cause trouble.

What about packages that use a custom bootstrap script and/or gnulib?
Should gnulib be updated too?  This is potentially dangerous.  What
about packages which have AC_PREREQ for an Autoconf version that is
not yet packaged for Debian, or depend on a new Automake
version/feature (a minor issue, but it has happened in the past)?

I also wonder why debian/autoreconf is needed given that autoreconf
is recursive.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87oawpiz4s.GNUs_not_UNIX!%ya...@gnu.org

Re: Autoreconfing guide

[Paul Wise]

On Wed, Jul 16, 2014 at 1:14 AM, Wookey wrote:

> https://wiki.debian.org/Autoreconf

Please mention the need to Build-Depend on any packages containing .m4
files that are embedded in the orig.tar.gz. For example, a lot of
packages use macros from autoconf-archive and some -dev packages
contain macros.

I note there are still some upstreams who do not trust autoconf. For
example the e2fsprogs maintainer recently rejected my patch to remove
autotools cruft from the git repository. As a result of autoconf
changes, he copied part (AM_MKINSTALLDIRS) of the nls.m4 file into the
acinclude.m4 file.

I wonder if lintian should be mentioning dh-autoreconf as best
practice at info/pedantic level?

I also wonder if autotools upstream should move away from storing
artefacts in the orig.tar.gz. A better model might be to run autotools
on the build machine and have an option that is run on
new/normal/modern platforms to spit out a blob of
shell/VBScript/something for ancient/weird/legacy/different platforms.
Presumably anyone trying to build for old platforms also has access to
a modern platform. Anyone seen plans for something like that?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6GAhUjeKX2wBOHrr_G6MTCoa+iakrTw8RL2vtPx=qd...@mail.gmail.com

Re: Autoreconfing guide

[Paul Wise]

On Wed, Jul 16, 2014 at 1:14 AM, Wookey  wrote:

> https://wiki.debian.org/Autoreconf

Could you mention this in DevNews?

https://wiki.debian.org/DeveloperNews

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6eng4pz2fcwamgmaaykbhr6gaoutck3512kkwtr3vy...@mail.gmail.com

Re: Autoreconfing guide

[Wookey]

+++ Yavor Doganov [2014-07-16 00:45 +0300]:
> Russ Allbery wrote:
> > I would still use dh-autoreconf.  It's not as critical, since it's
> > unlikely to be necessary for supporting new architectures, but I
> > think the Autoconf and Automake files are better treated as source,
> > and the generated files regenerated on every build.
> 
> However, this is not how the GNU build system is intended to be used.

The autotools view that the stuff shipped with the source is
sacrosanct has caused (and is causing) orders of magnitude more
trouble than reautoconfing at build time does.

We now have lots of experience which shows that reautoconfing hardly
ever breaks things any more (and if it does that's something we should
know about and fix). We also have lots of experience to show that using
the old files shipped with the source does not work on new
architectures and generates enormous amounts of largely pointless
mechanical work for porters and maintainers. 

> > This ensures that the files can still be generated from the source,
> > which in turn ensures that anyone wanting to make changes to the
> > source package will be able to do so easily.
>   
> This is an obvious plus, but consider the cons:

Russ has explained why your list of cons is, overall, not convincing.

If people want to expand the rationale section of the page on pro's
and cons, then that's fine - it's a useful place to collect such info,
but do please make sure any claims of problems are evidence-backed.

I was mostly hoping for additional info on the practical changes
maintainers should know about (very few of whom know anything about
the autotools really work). (if your package contains construct 'foo'
then it will do X and should be updated to form 'bar'). Or examples of
things which break in practice, and what should be done to fix them..

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140715230748.gi22...@stoneboat.aleph1.co.uk

Re: Autoreconfing guide

[Russ Allbery]

Yavor Doganov  writes:
> Russ Allbery wrote:

>> I would still use dh-autoreconf.  It's not as critical, since it's
>> unlikely to be necessary for supporting new architectures, but I think
>> the Autoconf and Automake files are better treated as source, and the
>> generated files regenerated on every build.

> However, this is not how the GNU build system is intended to be used.

Meh.  I think this is a non-issue.  Most free software is used in ways
that it wasn't originally designed for, and I think this is a clearly
superior way to use it on platforms where we have the right tools.

The pre-built configure scripts and Makefiles still provide valuable
portability to systems where it's hard to get all the right tools
installed.

>> This ensures that the files can still be generated from the source,
>> which in turn ensures that anyone wanting to make changes to the source
>> package will be able to do so easily.
>   
> This is an obvious plus, but consider the cons:

> - It can provide non-deterministic builds for packages which misuse
>   the build system (improper quotation, usage of broken third-party
>   macros, etc).

No, it's not non-deterministic.  It's quite deterministic; it just may be
broken with newer versions of the tools, just like badly written C code
may be broken by newer versions of the compiler.  This is exactly *why*
you should always regenerate from source: so that you can catch those bugs
and *fix* them.  That's part of the point of free software.

> - It can provide non-deterministic builds for legitimate use, when a
>   macro changes its semantics (this used to happen quite a lot in the
>   past).

Which is equivalent to saying that unmaintained Autoconf or Automake files
will *break* the builds for legitimate uses, like needing to modify some
part of the build system and finding that it can't be recreated with the
Autoconf and Automake currently available.  This is why these bugs should
be flushed out and fixed.

> - It can introduce bugs for no good reason if a buggy
>   Autoconf/Automake version is used (either an upstream release that
>   introduced a regression or caused by a Debian patch).

Well, obviously I completely disagree with "no good reason."  Yes,
actually using our build chain will uncover bugs in our build chain, so
that we can then fix them.  This is very good, even if it's painful when
we find the bugs.

> - Packages may (will?) FTBFS if they're silently "upgraded" to a new
>   Autoconf/Automake release that requires sourceful changes to
>   configure.ac/Makefile.am's/etc and such changes are not made by the
>   upstream/Debian maintainer (consider binNMUs, or the regular archive
>   rebuilds).

Again, this is no different than buiding with a new C compiler.  Those are
bugs that should be fixed, and better that we know about them than not.

> - All of the above can happen on a large scale if a big library
>   transition is involved and some stack of packages is being rebuilt.

I find your concerns excessively alarmist.

I have been rebuilding all the Autoconf and Automake files from scratch
for all packages I maintain for quite some time now, including some very
complex packages and packages with a mess of Autoconf macros, and have had
few problems apart from a few latent upstream bugs that were flushed out
and are now fixed.  The only significant problem that I had that fell into
one of your categories was the need to add:

m4_ifdef([AM_PROG_AR], [AM_PROG_AR])

to configure.ac in several of my packages due to an Automake behavior
change.  I've had considerably more work to do with C++ compiler
transitions.

If a particular package uses Autoconf and Automake in such a fragile and
broken way that it keeps causing problems, maybe it's useful as a matter
of expediency to fall back on not rebuilding the files until those bugs
can be fixed.  I know some packages mangled those tools very badly in the
past.  But for the vast majority of packages this works fine, or with at
most minor patches that upstream is happy to take.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87r41ml144@windlord.stanford.edu

Re: Autoreconfing guide

[Yavor Doganov]

Russ Allbery wrote:
> I would still use dh-autoreconf.  It's not as critical, since it's
> unlikely to be necessary for supporting new architectures, but I
> think the Autoconf and Automake files are better treated as source,
> and the generated files regenerated on every build.

However, this is not how the GNU build system is intended to be used.

> This ensures that the files can still be generated from the source,
> which in turn ensures that anyone wanting to make changes to the
> source package will be able to do so easily.
  
This is an obvious plus, but consider the cons:

- It can provide non-deterministic builds for packages which misuse
  the build system (improper quotation, usage of broken third-party
  macros, etc).
- It can provide non-deterministic builds for legitimate use, when a
  macro changes its semantics (this used to happen quite a lot in the
  past).
- It can introduce bugs for no good reason if a buggy
  Autoconf/Automake version is used (either an upstream release that
  introduced a regression or caused by a Debian patch).
- Packages may (will?) FTBFS if they're silently "upgraded" to a new
  Autoconf/Automake release that requires sourceful changes to
  configure.ac/Makefile.am's/etc and such changes are not made by the
  upstream/Debian maintainer (consider binNMUs, or the regular archive
  rebuilds).
- All of the above can happen on a large scale if a big library
  transition is involved and some stack of packages is being rebuilt.



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87bnsqguto.GNUs_not_UNIX!%ya...@gnu.org

Re: Autoreconfing guide

[Guido van Steen]

} but I think the Autoconf and Automake files are better treated as source,
} and the generated files regenerated on every build.

I thought that regenerating generated files was achieved by adding build-depends
on autoconf and automake, and that autoreconf was only needed to generate
config.guess and config.sub.

Apparently I was wrong. Thank you for pointing this out! Next time I will
use autoreconf as well.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/camtvz+sfqan-xbybgyvogypkw8mymfckhc7h42tk6wkbt-4...@mail.gmail.com

Re: Autoreconfing guide

[Russ Allbery]

Guido van Steen  writes:

> I maintain a package that does not need any compiling. Still upstream
> development is done using autoconf and autotools. Building the Debian
> package yields a single binary package for all architectures. AFAIK in
> this case I need neither dh-autoreconf nor autotools-dev. Correct me if
> I am wrong though... IMO this could be useful information for the wiki
> as well.

I would still use dh-autoreconf.  It's not as critical, since it's
unlikely to be necessary for supporting new architectures, but I think the
Autoconf and Automake files are better treated as source, and the
generated files regenerated on every build.  This ensures that the files
can still be generated from the source, which in turn ensures that anyone
wanting to make changes to the source package will be able to do so
easily.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87bnsqmka5@windlord.stanford.edu

Re: Autoreconfing guide

[Guido van Steen]

Hi Wooky,

} https://wiki.debian.org/Autoreconf

Your wikipage looks very good! Thanks!

I maintain a package that does not need any compiling. Still upstream
development is done using autoconf and autotools. Building the Debian
package yields a single binary package for all architectures. AFAIK in
this case I need neither dh-autoreconf nor autotools-dev. Correct me
if I am wrong though... IMO this could be useful information for the
wiki as well.

I also find https://wiki.debian.org/AutoTools/autoconf quite interesting.

Best wishes,

Guido


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/camtvz+vsgx1rbycbxod8ypbeuffd6fsyekox7wdec3a4rsy...@mail.gmail.com

Re: Autoreconfing guide

[Wookey]

+++ Jakub Wilk [2014-07-15 21:43 +0200]:
> * Wookey , 2014-07-15, 18:14:
> >>>I've written a wiki page on how and when to use dh-autoreconf
> >>>and autotools-dev.
> 
> Awesome, thanks!
> 
> >https://wiki.debian.org/Autoreconf
> 
> What is “'foreign' context” and how do you set it?

Yeah I didn't have time to look that up and remind myself:



It's actually 'foreign strictness'

https://www.gnu.org/software/automake/manual/html_node/Strictness.html
https://www.gnu.org/software/automake/manual/html_node/Options-generalities.html


Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140715195956.gh22...@stoneboat.aleph1.co.uk

Re: Autoreconfing guide

[Jakub Wilk]

* Wookey , 2014-07-15, 18:14:
I've written a wiki page on how and when to use dh-autoreconf and 
autotools-dev.


Awesome, thanks!


https://wiki.debian.org/Autoreconf


What is “'foreign' context” and how do you set it?

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140715194332.ga1...@jwilk.net

Re: Autoreconfing guide

[Wookey]

+++ Guido van Steen [2014-07-15 19:09 +0200]:
> > I've written a wiki page on how and when to use dh-autoreconf and 
> > autotools-dev.
> 
> Could you provide an url?

Doh!

https://wiki.debian.org/Autoreconf


Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140715171404.gg22...@stoneboat.aleph1.co.uk

Re: Autoreconfing guide

[Guido van Steen]

> I've written a wiki page on how and when to use dh-autoreconf and 
> autotools-dev.

Could you provide an url?

Thank you!

Guido van Steen


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/camtvz+vwvz3v4dhurm92cq_pzfcikvu-f4zy8zn+hyl_dgr...@mail.gmail.com

Autoreconfing guide

[Wookey]

I've written a wiki page on how and when to use dh-autoreconf and autotools-dev.
(having done a pile of updating like this recently)

People might like to comment on it/improve it.

(there are more examples needed for using both together, and on
updating macros from older conventions, and on tricky cases like
configure in top-level, configure.ac in subdir with config.* files)


Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140715170553.gf22...@stoneboat.aleph1.co.uk