Menu
▾
▴
libdbi-devel
|
From: <jp...@re...> - 2014-01-21 09:27:19
|
Hi, libdbi ships with archaic version of automake which doesn't support e.g. aarch64 which is currently officially supported in many (not-only Linux) distributions (Fedora, Gentoo, etc.). Could you please update the automake scripts (config.guess, config.sub, depcomp etc.)? Kind regards -- Jan Pacner |
|
From: Jan E. <je...@in...> - 2014-01-21 18:33:31
|
On Tuesday 2014-01-21 10:27, jp...@re... wrote: >Hi, > >libdbi ships with archaic version of automake which doesn't support e.g. >aarch64 which is currently officially supported in many (not-only Linux) >distributions (Fedora, Gentoo, etc.). > >Could you please update the automake scripts (config.guess, config.sub, >depcomp etc.)? Do you happen to know the minimum version needed to bring the features you seek? |
|
From: <jp...@re...> - 2014-01-23 14:36:56
|
Up until now, I've used version automake-1.12.5 with timestamp 2012-09-25. But it's possible (and I'd rather prefer it) to use a newer one (IMHO a half-year old one should be enough stable). -- Jan Pacner On 01/21/2014 07:33 PM, Jan Engelhardt wrote: > On Tuesday 2014-01-21 10:27, jp...@re... wrote: > >> Hi, >> >> libdbi ships with archaic version of automake which doesn't support e.g. >> aarch64 which is currently officially supported in many (not-only Linux) >> distributions (Fedora, Gentoo, etc.). >> >> Could you please update the automake scripts (config.guess, config.sub, >> depcomp etc.)? > > Do you happen to know the minimum version needed to bring the features > you seek? > |
|
From: <mar...@mh...> - 2014-01-23 23:05:40
|
jp...@re... writes: > Up until now, I've used version automake-1.12.5 with timestamp > 2012-09-25. But it's possible (and I'd rather prefer it) to use a newer > one (IMHO a half-year old one should be enough stable). > Hi, I just checked my local copies. The last release was built from the CVS sources which still have the automake 1.11 files. My current git local copy uses automake 1.14, so if I should package a new release anytime soon it would have automake files newer than what you asked for. In any case, what do you think about adding "--force-missing" to the automake call in ./autogen.sh to facilitate easier updating to newer automake releases? regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 |
|
From: Jan E. <je...@in...> - 2014-01-24 01:50:44
|
On Friday 2014-01-24 00:07, mar...@mh... wrote: >In any case, what do you think about adding "--force-missing" to the >automake call in ./autogen.sh to facilitate easier updating to newer >automake releases? gmake is usually capable of refreshing things "as needed", so when autoreconf ought to be run, passing -f all the time seems free. Speaking of which, autogen.sh has too much cruft. It should be removed and/or replaced to only call `autoreconf -fi`. And perhaps `rm -Rf autom4te.cache` because that seems to go unused. |
|
From: Markus H. <mar...@mh...> - 2014-01-24 08:18:06
|
At 2014-01-24 02:50 Jan Engelhardt was heard to say: > Speaking of which, autogen.sh has too much cruft. It should be removed > and/or replaced to only call `autoreconf -fi`. And perhaps `rm -Rf > autom4te.cache` because that seems to go unused. Thanks for that, I was not aware of autoreconf. It certainly make sense to use that as it seems to do the right thing automagically. However, I'd prefer to keep autogen.sh around, even if it contains just a single call to autoreconf, for the sake of backwards compatibility. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 |
|
From: <jp...@re...> - 2014-01-24 10:15:46
|
> It certainly make sense > to use that as it seems to do the right thing automagically. However, > I'd prefer to keep autogen.sh around, even if it contains just a single > call to autoreconf, for the sake of backwards compatibility. You must be right. I agree with this decision. Thanks -- Jan Pacner |
|
From: Jan E. <je...@in...> - 2014-01-24 12:23:34
|
On Friday 2014-01-24 09:17, Markus Hoenicka wrote: >At 2014-01-24 02:50 Jan Engelhardt was heard to say: >> Speaking of which, autogen.sh has too much cruft. It should be removed >> and/or replaced to only call `autoreconf -fi`. And perhaps `rm -Rf >> autom4te.cache` because that seems to go unused. > >Thanks for that, I was not aware of autoreconf. It certainly make sense >to use that as it seems to do the right thing automagically. However, >I'd prefer to keep autogen.sh around, even if it contains just a single >call to autoreconf, for the sake of backwards compatibility. No objections, I use an autogen.sh myself sometimes. I sent up a new autogen.sh into the repo. Now, release? |
|
From: Markus H. <mar...@mh...> - 2014-01-24 12:55:25
|
At 2014-01-24 13:23 Jan Engelhardt was heard to say: > > Now, release? > Well, why not. We just need to take care of your changes of the driver interface. Although this does not affect the libtool versioning (if I understand your changes correctly), we have claimed in the past that 0.9.x drivers work with any 0.9.y library. If I recall our version number black magic correctly, this would require us to start 1.0 (or 0.10 ?) series of both library and drivers. BTW which test platforms do we have at our disposal? I can contribute FreeBSD 9.2 and Debian testing. I've seen a bunch of 0.9.0 test failures on the Debian build farm lately on some non-x86/x86-64 platforms. Maybe we should try to fix those problems before releasing a new version. I'll compile a list of test failures asap so we can discuss what can be fixed in a reasonable timeframe. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 |
|
From: Jan E. <je...@in...> - 2014-01-24 14:55:56
|
On Friday 2014-01-24 13:55, Markus Hoenicka wrote: >At 2014-01-24 13:23 Jan Engelhardt was heard to say: >> >> Now, release? > >Well, why not. We just need to take care of your changes of the driver >interface. Although this does not affect the libtool versioning (if I >understand your changes correctly), we have claimed in the past that >0.9.x drivers work with any 0.9.y library. If I recall our version >number black magic correctly, this would require us to start 1.0 (or >0.10 ?) series of both library and drivers. So just make it a 1.0. (The libtool numbering is correct already.) >BTW which test platforms do we have at our disposal? Platforms I use in the current context: openSUSE, mingw-w64 Available build platforms: openSUSE x86/x64, ppc/ppc64 Fedora and other Redhats x86/x64 Cygwin x86/x64 mingw-w64 x86/x64 mingw-org x86 If you have a dsc that is accepted by OpenBuildService, can also add the Debian targets. |
Thanks for helping keep SourceForge clean.
X