#936 closed defect (fixed)
hulahop autotools seems broken
Reported by: | tomeu | Owned by: | erikos |
---|---|---|---|
Priority: | High | Milestone: | |
Component: | hulahop | Version: | Unspecified |
Severity: | Major | Keywords: | |
Cc: | jonas | Distribution/OS: | Unspecified |
Bug Status: | Assigned |
Description
Jonas Smedegaard reports:
The autotools shipped with hulahop 0.4.9 seems broken. * The option --disable-maintainer-mode is unsupported * libtool fails, seemingly treating compile flags as build options I have worked around it for now in the Debian packaging by regenerating autotools, but ideally it should be fixed upstream. As a related note, I noticed (because I now keep close track of *all* licensing info. including autogenerated files) that the autotools files shipped do not always progress: sometimes (I believe it was with sugar-toolkit but might be another core library) a newer release ship with older autotools files (e.g. not shipping the - funny in our context - - m4/ltsugar.mk file).
Change History (8)
comment:1 in reply to: ↑ description ; follow-up: ↓ 3 Changed 14 years ago by jonas
comment:2 Changed 14 years ago by jonas
Other packages, like "sugar", lack AM_MAINTAINER_MODE too.
comment:3 in reply to: ↑ 1 Changed 14 years ago by tomeu
Replying to jonas:
Replying to tomeu:
- The option --disable-maintainer-mode is unsupported
adding AM_MAINTAINER_MODE to configure.ac fixes this.
More info here: http://www.gnu.org/software/hello/manual/automake/maintainer_002dmode.html
That page also mentions why you might not want to use that macro, but read on...
- libtool fails, seemingly treating compile flags as build options
Updating autotools (using autorecond, relibtoolize or whatever) should fix this.
autogen.sh won't work for this?
I suspect that the problem is triggered when you use an older libtool (1.5.26) and
a distro uses a newer one (currently 2.2.6a in Debian unstable) and AM_MAINTAINER_MODE
is not possible to disable.
In other words, I see this as a good example of why it makes sense to use
AM_MAINTAINER_MODE: It helps fixate source for distributors.
Ok, have checked some GNOME modules and all use it, so I guess it's of use for packagers and will add it to our modules.
As a related note, I noticed (because I now keep close track of *all*
licensing info. including autogenerated files) that the autotools files
shipped do not always progress: sometimes (I believe it was with
sugar-toolkit but might be another core library) a newer release ship
with older autotools files (e.g. not shipping the - funny in our context
- - m4/ltsugar.mk file).
This is "fixed" by coordinating among developers to consistently use recent autotools
when releasing tarballs.
comment:4 Changed 14 years ago by tomeu
- Milestone changed from Unspecified by Release Team to 0.86
- Priority changed from Unspecified by Maintainer to High
- Severity changed from Unspecified to Major
comment:5 Changed 14 years ago by erikos
- Owner changed from marcopg to erikos
- Status changed from new to assigned
comment:6 Changed 14 years ago by erikos
- Bug Status changed from Unconfirmed to Assigned
The maintainer mode has been pushed.
94266b8b (Tomeu Vizoso 2009-06-17 19:18:59 +0200 22) AM_MAINTAINER_MODE
comment:7 Changed 14 years ago by erikos
- Cc jonas added
- Resolution set to fixed
- Status changed from assigned to closed
I guess this fixes this ticket. Feel free to reopen if not.
Replying to tomeu:
adding AM_MAINTAINER_MODE to configure.ac fixes this.
More info here: http://www.gnu.org/software/hello/manual/automake/maintainer_002dmode.html
That page also mentions why you might not want to use that macro, but read on...
Updating autotools (using autorecond, relibtoolize or whatever) should fix this.
I suspect that the problem is triggered when you use an older libtool (1.5.26) and
a distro uses a newer one (currently 2.2.6a in Debian unstable) and AM_MAINTAINER_MODE
is not possible to disable.
In other words, I see this as a good example of why it makes sense to use
AM_MAINTAINER_MODE: It helps fixate source for distributors.
This is "fixed" by coordinating among developers to consistently use recent autotools
when releasing tarballs.