Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Ubuntu Development (http://www.linux-archive.org/ubuntu-development/)
-   -   libtool updates (http://www.linux-archive.org/ubuntu-development/194777-libtool-updates.html)

Scott James Remnant 11-17-2008 09:13 AM

libtool updates
 
I notice a lot of packages updating libtool in a variety of ways, so I'd
like to make the following notes:

The one, and only, proper and correct way to do this is:

autoreconf -f -i

That will update all of the tools to the current version, in the right
order.

(yes, we know cdbs doesn't do this ... that's a cdbs bug)


If you do this, *send your patches to upstream and Debian*

Scott
--
Scott James Remnant
scott@canonical.com
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Colin Watson 11-18-2008 12:05 PM

libtool updates
 
On Mon, Nov 17, 2008 at 10:13:23AM +0000, Scott James Remnant wrote:
> I notice a lot of packages updating libtool in a variety of ways, so I'd
> like to make the following notes:
>
> The one, and only, proper and correct way to do this is:
>
> autoreconf -f -i
>
> That will update all of the tools to the current version, in the right
> order.

If you run across a package that uses both gettext and gnulib (you can
spot the latter by looking for files called gnulib-cache.m4), be careful
with this, as it won't work right unless something along the lines of
http://lists.gnu.org/archive/html/bug-gnulib/2008-11/msg00265.html is
applied. Consult an expert if in doubt.

--
Colin Watson [cjwatson@ubuntu.com]

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

James Westby 12-02-2008 11:08 AM

libtool updates
 
On Mon, 2008-11-17 at 10:13 +0000, Scott James Remnant wrote:
> I notice a lot of packages updating libtool in a variety of ways, so I'd
> like to make the following notes:
>
> The one, and only, proper and correct way to do this is:
>
> autoreconf -f -i
>
> That will update all of the tools to the current version, in the right
> order.

Hi Scott,

Thanks for this information. I would like to clarify about what this
call should replace. I assume it replaces calling autoreconf with any
other arguments, and indeed calling all the scripts individually, is
that right? Should we do this instead of just calling libtoolize
without auto*? What about automake but none of the others?

You mention cdbs, is the correct thing to do with that to always
specify all DEB_AUTO_UPDATE_* or none of them?

Failures caused by this are easy to solve, but I'm always unsure if I
am solving it in the correct manner, or whether it will just break again
soon. Knowing what is correct also makes it a lot easier to take
these patches to Debian.

Thanks,

James


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Steve Langasek 12-02-2008 07:11 PM

libtool updates
 
On Tue, Dec 02, 2008 at 12:08:00PM +0000, James Westby wrote:
> On Mon, 2008-11-17 at 10:13 +0000, Scott James Remnant wrote:
> > I notice a lot of packages updating libtool in a variety of ways, so I'd
> > like to make the following notes:

> > The one, and only, proper and correct way to do this is:

> > autoreconf -f -i

> > That will update all of the tools to the current version, in the right
> > order.

> Hi Scott,

> Thanks for this information. I would like to clarify about what this
> call should replace. I assume it replaces calling autoreconf with any
> other arguments, and indeed calling all the scripts individually, is
> that right? Should we do this instead of just calling libtoolize
> without auto*? What about automake but none of the others?

Calling libtoolize on its own is always wrong because this can result in
version skew between ltmain.sh and (aclocal.m4/configure).

Calling automake on its own is always wrong because this can result in
version skew between **/Makefile.in and (aclocal.m4/configure).

Both of these issues can be addressed by calling "autoreconf" instead.

There are other combinations that are "safe" (libtoolize+aclocal+autoconf
w/o automake; automake+aclocal+autoconf w/o libtoolize), but distinguishing
the safe cases from the unsafe ones requires finer knowledge of autotools
workings than we can probably expect most developers to retain, so as a
general rule, using "autoreconf" is probably best.

> You mention cdbs, is the correct thing to do with that to always
> specify all DEB_AUTO_UPDATE_* or none of them?

That probably depends on whether you have a reason in that package to modify
any of the other autotools input files?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

James Westby 12-02-2008 07:21 PM

libtool updates
 
On Tue, 2008-12-02 at 12:11 -0800, Steve Langasek wrote:
> Calling libtoolize on its own is always wrong because this can result in
> version skew between ltmain.sh and (aclocal.m4/configure).
>
> Calling automake on its own is always wrong because this can result in
> version skew between **/Makefile.in and (aclocal.m4/configure).
>
> Both of these issues can be addressed by calling "autoreconf" instead.
>
> There are other combinations that are "safe" (libtoolize+aclocal+autoconf
> w/o automake; automake+aclocal+autoconf w/o libtoolize), but distinguishing
> the safe cases from the unsafe ones requires finer knowledge of autotools
> workings than we can probably expect most developers to retain, so as a
> general rule, using "autoreconf" is probably best.

Thanks I'm happy to use this rule for now and to learn about the other
cases in the future.

> > You mention cdbs, is the correct thing to do with that to always
> > specify all DEB_AUTO_UPDATE_* or none of them?
>
> That probably depends on whether you have a reason in that package to modify
> any of the other autotools input files?

I was asking this as I expected the answer above, and as cdbs provides
these than a method to run autoreconf, I assume that specifying e.g.
just "DEB_AUTO_UPDATE_LIBTOOL = pre" is going to hit the same sort
of problems. Therefore it seems like specifying all of them, or adding
a makefile rule to actually run "autoreconf" would be the best way to
handle it. Maybe there is a subtlety I am missing though.

Thanks,

James



--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Alexander Sack 12-03-2008 11:40 AM

libtool updates
 
On Tue, Dec 02, 2008 at 12:11:21PM -0800, Steve Langasek wrote:
> On Tue, Dec 02, 2008 at 12:08:00PM +0000, James Westby wrote:
> > On Mon, 2008-11-17 at 10:13 +0000, Scott James Remnant wrote:
> > > I notice a lot of packages updating libtool in a variety of ways, so I'd
> > > like to make the following notes:
>
> > > The one, and only, proper and correct way to do this is:
>
> > > autoreconf -f -i
>
> > > That will update all of the tools to the current version, in the right
> > > order.
>
> > Hi Scott,
>
> > Thanks for this information. I would like to clarify about what this
> > call should replace. I assume it replaces calling autoreconf with any
> > other arguments, and indeed calling all the scripts individually, is
> > that right? Should we do this instead of just calling libtoolize
> > without auto*? What about automake but none of the others?
>
> Calling libtoolize on its own is always wrong because this can result in
> version skew between ltmain.sh and (aclocal.m4/configure).
>
> Calling automake on its own is always wrong because this can result in
> version skew between **/Makefile.in and (aclocal.m4/configure).
>
> Both of these issues can be addressed by calling "autoreconf" instead.
>
> There are other combinations that are "safe" (libtoolize+aclocal+autoconf
> w/o automake; automake+aclocal+autoconf w/o libtoolize), but distinguishing
> the safe cases from the unsafe ones requires finer knowledge of autotools
> workings than we can probably expect most developers to retain, so as a
> general rule, using "autoreconf" is probably best.

So I guess cdbs should get a DEB_AUTO_UPDATE_AUTORECONF hint.

Patch for discussion:

diff -Nru cdbs-0.4.52ubuntu7/1/class/autotools-files.mk.in cdbs-0.4.52ubuntu8/1/class/autotools-files.mk.in
--- cdbs-0.4.52ubuntu7/1/class/autotools-files.mk.in 2008-08-29 15:07:49.000000000 +0200
+++ cdbs-0.4.52ubuntu8/1/class/autotools-files.mk.in 2008-12-03 13:30:10.000000000 +0100
@@ -44,6 +44,24 @@
endif
endif

+ifneq ($(DEB_AUTO_UPDATE_AUTORECONF), )
+ifneq ($(DEB_AUTO_UPDATE_ACLOCAL), )
+$(warning WARNING: DEB_AUTO_UPDATE_AUTORECONF conflicts with DEB_AUTO_UPDATE_ACLOCAL)
+endif
+ifneq ($(DEB_AUTO_UPDATE_AUTOCONF), )
+$(warning WARNING: DEB_AUTO_UPDATE_AUTORECONF conflicts with DEB_AUTO_UPDATE_AUTOCONF)
+endif
+ifneq ($(DEB_AUTO_UPDATE_AUTOHEADERS), )
+$(warning WARNING: DEB_AUTO_UPDATE_AUTORECONF conflicts with DEB_AUTO_UPDATE_AUTOHEADERS)
+endif
+ifneq ($(DEB_AUTO_UPDATE_AUTOMAKE), )
+$(warning WARNING: DEB_AUTO_UPDATE_AUTORECONF conflicts with DEB_AUTO_UPDATE_LIBTOOL)
+endif
+ifneq ($(DEB_AUTO_UPDATE_LIBTOOL), )
+$(warning WARNING: DEB_AUTO_UPDATE_AUTORECONF conflicts with DEB_AUTO_UPDATE_LIBTOOL)
+endif
+endif
+
common-configure-arch common-configure-indep:: debian/stamp-autotools-files
debian/stamp-autotools-files:
$(if $(filter pre,$(DEB_AUTO_UPDATE_LIBTOOL)),cd $(DEB_SRCDIR) && libtoolize -c -f -i)
@@ -51,6 +69,7 @@
$(if $(DEB_AUTO_UPDATE_AUTOCONF),if [ -e $(DEB_SRCDIR)/configure.ac ] || [ -e $(DEB_SRCDIR)/configure.in ]; then cd $(DEB_SRCDIR) && `which autoconf$(DEB_AUTO_UPDATE_AUTOCONF) || which autoconf`; fi)
$(if $(DEB_AUTO_UPDATE_AUTOHEADER),if [ -e $(DEB_SRCDIR)/configure.ac ] || [ -e $(DEB_SRCDIR)/configure.in ]; then cd $(DEB_SRCDIR) && `which autoheader$(DEB_AUTO_UPDATE_AUTOHEADER) || which autoheader` ; fi)
$(if $(DEB_AUTO_UPDATE_AUTOMAKE),if [ -e $(DEB_SRCDIR)/Makefile.am ]; then cd $(DEB_SRCDIR) && automake-$(DEB_AUTO_UPDATE_AUTOMAKE) $(DEB_AUTOMAKE_ARGS) ; fi)
+ $(if $(DEB_AUTO_UPDATE_AUTORECONF),cd $(DEB_SRCDIR) && autoreconf -f -i; fi)
touch debian/stamp-autotools-files

clean::
diff -Nru cdbs-0.4.52ubuntu7/1/class/autotools-vars.mk.in cdbs-0.4.52ubuntu8/1/class/autotools-vars.mk.in
--- cdbs-0.4.52ubuntu7/1/class/autotools-vars.mk.in 2008-08-29 15:07:49.000000000 +0200
+++ cdbs-0.4.52ubuntu8/1/class/autotools-vars.mk.in 2008-12-03 13:32:31.000000000 +0100
@@ -80,7 +80,7 @@
endif
endif

-ifneq (:, $(DEB_AUTO_UPDATE_AUTOCONF):$(DEB_AUTO_UPDATE_AUTO HEADER))
+ifneq (::, $(DEB_AUTO_UPDATE_AUTOCONF):$(DEB_AUTO_UPDATE_AUTO HEADER):$(DEB_AUTO_UPDATE_AUTORECONF))
ifeq ($(DEB_AUTO_UPDATE_AUTOCONF), $(DEB_AUTO_UPDATE_AUTOHEADER))
# avoid duped build-dependencies
ifeq ($(DEB_AUTO_UPDATE_AUTOCONF), 2.13)
@@ -104,6 +104,13 @@
CDBS_BUILD_DEPENDS := $(CDBS_BUILD_DEPENDS), autoconf
endif
endif
+ifneq (, $(DEB_AUTO_UPDATE_AUTORECONF))
+ifeq ($(DEB_AUTO_UPDATE_AUTORECONF), 2.13)
+CDBS_BUILD_DEPENDS := $(CDBS_BUILD_DEPENDS), autoconf2.13
+else
+CDBS_BUILD_DEPENDS := $(CDBS_BUILD_DEPENDS), autoconf
+endif
+endif
endif
endif

diff -Nru cdbs-0.4.52ubuntu7/debian/changelog cdbs-0.4.52ubuntu8/debian/changelog
--- cdbs-0.4.52ubuntu7/debian/changelog 2008-08-29 15:07:49.000000000 +0200
+++ cdbs-0.4.52ubuntu8/debian/changelog 2008-12-03 13:36:35.000000000 +0100
@@ -1,3 +1,10 @@
+cdbs (0.4.52ubuntu8) UNRELEASED; urgency=low
+
+ * 1/class/autotools-files.mk.in, 1/class/autotools-vars.mk.in:
+ first attempt on _AUTORECONF support
+
+ -- Alexander Sack <asac@ubuntu.com> Wed, 03 Dec 2008 12:30:28 +0100
+
cdbs (0.4.52ubuntu7) intrepid; urgency=low

* Remove need for THIS_SHOULD_GO_TO_UNSTABLE from kde4.m

- Alexander


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Morten Kjeldgaard 12-04-2008 09:00 AM

libtool updates
 
On 03/12/2008, at 13.40, Alexander Sack wrote:

> So I guess cdbs should get a DEB_AUTO_UPDATE_AUTORECONF hint.

That's an excellent idea. I've long been puzzled how awkward it is to
update the autotools with CDBS when you've patched one of the files.

DEB_AUTO_UPDATE_AUTOCONF needs to be assigned to a version number,
whereas *_UPDATE_LIBTOOL is "pre" or "post". Your patch would do the
correct thing and also simplify usage.

Cheers,
Morten


--
Morten Kjeldgaard
mok0@ubuntu.com
Key fingerprint = FC53 53B2 81D1 27CA 45D5 F864 078C F31B 4048 25E7


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Martin Pitt 12-04-2008 07:55 PM

libtool updates
 
Hello Alex,

Alexander Sack [2008-12-03 13:40 +0100]:
> So I guess cdbs should get a DEB_AUTO_UPDATE_AUTORECONF hint.

Purely coincidentally I encountered a packaging situation where this
was necessary just necessary (first time ever, since I usually try
hard to avoid it). But when building packages from upstream VCS, it's
the only sane thing to do. Since the existing cdbs class is so
crackful and didn't work for me, I just ended up writing a manual rule
in my debian/rules.

> Patch for discussion:
> +ifneq (, $(DEB_AUTO_UPDATE_AUTORECONF))
> +ifeq ($(DEB_AUTO_UPDATE_AUTORECONF), 2.13)
> +CDBS_BUILD_DEPENDS := $(CDBS_BUILD_DEPENDS), autoconf2.13
> +else
> +CDBS_BUILD_DEPENDS := $(CDBS_BUILD_DEPENDS), autoconf

I don't like hardcoding particular, and ancient autoconf versions
here. If you do, you probably also need *blows the dust off*
automake1.4 and all that?

I haven't actually tested the patch, but it looks great. I suggest to
send it to the Debian BTS. For toolchainish changes like this we
should really be in sync with Debian, otherwise really bad things will happen.

Thanks!

Martin.

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Loc Minier 12-05-2008 09:04 PM

libtool updates
 
On Thu, Dec 04, 2008, Martin Pitt wrote:
> Purely coincidentally I encountered a packaging situation where this
> was necessary just necessary (first time ever, since I usually try
> hard to avoid it). But when building packages from upstream VCS, it's
> the only sane thing to do. Since the existing cdbs class is so
> crackful and didn't work for me, I just ended up writing a manual rule
> in my debian/rules.

You can also make dist your VCS snapshot and use that as a .orig
tarball.

--
Loc Minier

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


All times are GMT. The time now is 12:19 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.