GNU bug report logs -
#31262
makefile = 1.14, when I have 1.15
Previous Next
Reported by: Anthony Tran <anthot <at> pdx.edu>
Date: Wed, 25 Apr 2018 22:26:01 UTC
Severity: normal
Done: Mike Frysinger <vapier <at> gentoo.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 31262 in the body.
You can then email your comments to 31262 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-automake <at> gnu.org
:
bug#31262
; Package
automake
.
(Wed, 25 Apr 2018 22:26:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Anthony Tran <anthot <at> pdx.edu>
:
New bug report received and forwarded. Copy sent to
bug-automake <at> gnu.org
.
(Wed, 25 Apr 2018 22:26:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Is there something I need to change? Rather not have to revert back to
version 1.14 for this. I'm using this for the protobuf compiler 3.5.1, and
it spits out a message that I need to have 1.14 when I try "make."
Hoping to hear back soon,
- Student @ uni
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-automake <at> gnu.org
:
bug#31262
; Package
automake
.
(Thu, 26 Apr 2018 02:03:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 31262 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 04/25/2018 04:50 PM, Anthony Tran wrote:
> Is there something I need to change? Rather not have to revert back to
> version 1.14 for this. I'm using this for the protobuf compiler 3.5.1, and
> it spits out a message that I need to have 1.14 when I try "make."
Do you mean 'automake 1.14' vs. 'automake 1.15'? Usually, this can be
fixed by running 'autoreconf -fi' to force the newer version of automake
to rebuild Makefile.in files to no longer complain about version
mismatch; you may then have to manually run './config.status' before
'make' will work, to propagate the changes from Makefile.in to the
actual Makefile that is choking when you run 'make'.
But yes, it would also be nice if automake didn't bake in quite such a
version correlation between rules in a Makefile generated by an older
version of automake when coupled with rerunning a newer automake because
a Makefile.am changed.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-automake <at> gnu.org
:
bug#31262
; Package
automake
.
(Sun, 02 Jan 2022 09:11:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 31262 <at> debbugs.gnu.org (full text, mbox):
On Wed, 25 Apr 2018 21:02:49 -0500, Eric Blake wrote:
> But yes, it would also be nice if automake didn't bake in quite such a
> version correlation between rules in a Makefile generated by an older
> version of automake when coupled with rerunning a newer automake because
> a Makefile.am changed.
i'm not sure this trade-off is worth the effort. sure, it'd be nice, but
it'd be non-trivial to make sure backwards compat is maintained, and no one
would really ever test it.
we could do something like gettext where every release bundles all previous
versions and then selects the "right" one on the fly. but for distros that
patch things, that'll get messy too. and how many previous versions should
we bundle ?
some distros make it easy to install multiple versions in parallel. Gentoo
for example has automake-X.Y so devs can pick the right one for their setup,
with a common "automake" tool that detects the version used in the source
tree and runs the corresponding version if available. maybe we could make
that a more formal project ?
we could also make it easier for distros to install multiple versions in
parallel. the current info page logic doesn't make this easy.
Reply sent
to
Mike Frysinger <vapier <at> gentoo.org>
:
You have taken responsibility.
(Wed, 19 Jan 2022 08:14:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Anthony Tran <anthot <at> pdx.edu>
:
bug acknowledged by developer.
(Wed, 19 Jan 2022 08:14:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 31262-done <at> debbugs.gnu.org (full text, mbox):
archive 31262
thankyou
i think we'll just archive this as both infeasible & out-of-scope
-mike
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 16 Feb 2022 12:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 67 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.