Re: GNU Automake 1.12.1 released
Il 06/07/2012 10:26, Stefano Lattarini ha scritto: > I will soon push the attached patches to take care of the problem. > Note that they only re-introduce the $(mkdir_p) variable (because > is very easy to do so), but not the @mkdir_p@ substitution. Anyone > knows if this can create problems in practice? I've seen a couple of packages that did use @mkdir_p@. Honestly for what concerns Gentoo I think we're better off without either $(mkdir_p) and @mkdir_p@ and get them updated (of course the same does not apply for non-distribution contexts). What is causing us headaches are the portability warnings and the excessive use of -Werror in projects, but that's a different story (for what it's worth, the latest gettext release relies on AM_PROG_MKDIR_P still, which is causing warnings and thus failures with -Werror). -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: GNU Automake 1.12.1 released
Il 05/07/2012 11:26, Stefano Lattarini ha scritto: > How so? Removal of $(mkdir_p) is only planned for Automake 1.13, that is > still unreleased. Ehm Stefano, that's definitely not the case, I've been hitting that issue in Gentoo in many packages. https://bugs.gentoo.org/show_bug.cgi?id=automake-1.12 mkdir_p is gone in automake-1.12.1 for what we're concerned — I also listed it in the 1.12 instead of "planned for 1.13" in my own guide http://goo.gl/bda6l as I thought it was intentional. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: "rm -f core" in configure
Il 10/07/2012 23:32, Kenny Ho ha scritto: > > I am trying to convert one of my existing project to use automake but > after I run autoreconf and tried ./configure, I an "rm: cannot remove > `core': Is a directory" error. So I look into ./configure and found > "rm -f core" in the script. Now my project actually has a directory > name "core" but I don't think that rm command is related to my > source. Is the "core" directory reserved for use with automake? Is > there a way to work around this? "core" is the default name of the files created by Linux and other Unices containing the memory dump of a process that crashed. I guess the reason why there's that `rm` in there is because a number of autoconf tests do segfault, and in the case the user has a shell session with an unlimited core size, it would find these extraneous files. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: "rm -f core" in configure
Il 11/07/2012 18:33, Russ Allbery ha scritto: > To add one additional piece of information -- that rm was added because it > was discovered that some of Autoconf's probes for working compilers and > compiler properties would cause some buggy vendor compilers to core dump. I wish it was just problems with "buggy vendor compilers" — some of the tests, either default, custom, or autoconf-archive, actually cause the conftest result to segfault (and eventually coredump) even with GCC :/ -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: GNU Automake 1.11.6 released (fixes a SECURITY VULNERABILITY!)
Il 13/07/2012 10:50, Stefano Lattarini ha scritto: > Well, I'm really disappointed that nobody reported this upstream to us; > our non-Debian users would have been saved from two and a half years of > potential vulnerability :-/ It's worth noting that I just checked and Gentoo also applies the same patch, for us started by https://bugs.gentoo.org/show_bug.cgi?id=295357 The report quoted there refers to Jim who, if I'm not mistaken, works for RedHat, so I guess RHEL/Fedora/Centos are covered as well. So as much as I'd like to blame Debian, it's not really their fault :) -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: Using convenience libraries with non-recursive make
On 15/08/2012 08:26, Del Merritt wrote: > >nodist_EXTRA_libmyprog_la_SOURCES = dummy.cxx I would bet that this one is giving you trouble, but... why are you using multiple convenience libraries? If you're not going to install any of them, and the result is one final binary, you should just list all the sources to that one target. This also helps if you change some of the source files as it only needs to re-perform the final link step instead of having to do one or more ar calls. And I somehow doubt you want to use lib_LTLIBRARIES given the name (which will install the libraries as well). -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: Automake vs. Automake-NG
On 21/08/2012 07:32, Stefano Lattarini wrote: > do you think the transition would have been less painful (I really > hope the answer is yes, of course). >From a distribution point of view... it wouldn't have been any less painful. It would have meant we'd have even more packages using autoconf-2.1 than we still have right now.... -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: Automake vs. Automake-NG
On 21/08/2012 08:06, Paolo Bonzini wrote: > Exactly. The -NG moniker would have made no sense. What could have > made sense would have been a mapping like Yes that would have helped _a lot_. Another thing that would have helped would have been out-of-the-box support for multiple installed versions, whereas it seems most distributions had to reinvent a different way to deal with this. As of today, Gentoo still ships quite a few packages that use autoconf 2.1x, and that's quite painful as we can't update them to newer automake either (when they use automake at all), at least not without rebuilding the buildsystem altogether, which in turn means we have to keep automake-1.4 1.5 and so on around. Sigh! -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: Automake vs. Automake-NG
On 21/08/2012 09:30, Ralf Corsepius wrote: > In Fedora we already are pushing around package maintainers to pass > appropriate options to configure to revert this change, because silent > make rules are non-suitable for building distros in batch jobs. The same is true for Gentoo. > In other words, it is a fork with a backward incompatible API, a > probably backward-incompatible runtime environment and a different > target audience. > > Somewhat exaggerated: Yet another tool the world has not been waiting for. Or possibly what people expected Automake to be. Honestly I'm not sure how many automake-based projects really care about non-GNU make compatibility nowadays. A lot of them already don't work that well with anything but GNU make, and they just don't care. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [Automake-NG] Automake vs. Automake-NG
On 21/08/2012 09:47, Eric Blake wrote: > The > 'silent-rules' change in automake change did NOT make more builds > instantly silent, nor are we preventing you from your goal of noisy > builds for the Fedora buildbots. That being the case I retire my note as well — although it seems like most upstreams just decide to enable silent rules for good when they do. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [Automake-NG] Automake vs. Automake-NG
On 21/08/2012 13:44, Russ Allbery wrote: > Yes, but I (speaking as another distro maintainer) think that's a problem > with the upstreams that do that, rather than a problem with Automake in > how it offers the functionality. The upstreams just require some > education around how distros use unattended build logs to diagnose > problems! Oh I know that and don't fault the current documentation on this. I actually read it before as if automake-ng was going in the direction of having silent rules on by default, rather than having the current feature on by default. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [PATCH] {master} compile: remove support for $(INCLUDES)
On 22/08/2012 12:12, Paolo Bonzini wrote: > What about first making the warning visible always, not just with > -Wobsolete? And add to the message that support will be removed in > 1.14. +1 -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: building conditionnaly without using AM_CONDITIONAL
On 09/09/2012 04:05, Vincent Torri wrote: > > So i tried to set the 'all' rule to nothing in Makefile.am, it has no > effect. Is there a way to do what I want ? EXTRA_PROGRAMS = benchmark This way the program is not built during "make all". -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: Conditional nodist_EXTRA_*_SOURCES C++ linking idiom
On 17/09/2012 17:10, Matt Turner wrote: > Is this behavior by design? Is there some other way I can force C++ > linking conditionally? There is also the opposite case where this is useful: code like fdk-aac, which has to be compiled with a C++ compiler but uses none of the C++ library features and should be linked as C ... fdk-aac does this by rewriting the LINK variable for it [1] but it's a nasty hack and also relies on a dummy.c file. Having a foo_LANGUAGE = C or foo_LANGUAGE = C++ would be nice indeed... [1] http://goo.gl/aEUbG -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: Pre-built binary package
On 20/09/2012 10:56, Too, Justin A. wrote: > It should work wherever the user chooses to unpack the downloaded binary > distribution. That is, it doesn't have to be dropped into "/usr/local", > for example. I'd say google for "binreloc" but this reminds me a bit too much of autoinstall... and I don't think it ever worked or could ever work fine. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [RFC] Moving ltmain.sh and libtool.m4 into Automake
On 17/10/2012 08:27, Gary V. Vaughan wrote: >> > Creading a stand-alone libltdl package is a very good idea. > The separation will also make both packages much smaller and more manageable, > especially without all the contortions of trying to support all the different > ways of copying everything into the parent package that libltdl currently > supports. As a Gentoo Linux packager I have one more reason for the split! We currently follow whatever upstream packages together, unlike most binary distributions, so libtool and libltdl stay on the same package... that also means that we're bringing in the dependencies for ltmain/libtool.m4 at runtime for packages that are linking to libltdl. A split would be _extremely_ useful for us! -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: libtool libraries, dependencies and parallel builds
On 01/11/2012 09:18, Vincent Torri wrote: > lib_eo_libeo_la_LIBADD = $(top_builddir)/src/lib/eina/libeina.la Don't use $(top_builddir) and it should work just fine. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: building without $(top_builddir) in LDADD (was Re: libtool libraries, dependencies and parallel builds)
On 02/11/2012 16:16, Václav Zeman wrote: > How can I make this work as you have suggested without $(top_builddir)? Okay here's my rule of thumb (Stefano can give you the informed, developer opinion): - if it's declared in the same makefile, don't use $(top_builddir); - if it's declared on a different makefile, use $(top_builddir) and make sure SUBDIRS come first; - if possible, don't use recursive make at all. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: NASM/YASM support
On 17/11/2012 16:08, Stefano Lattarini wrote: > I know basically nothing about assembly, and this is just a quick reply > before bedtime, but... would this help? Not really. The problem with that, is that it's designed to support gas-style assembly (i.e. using the GCC frontend to compile the assembly). NASM at least does not conform to this that much, and it does not support the -c option. Basically what Luca is looking for is adding specific rules for using nasm-style command lines for building (yasm would follow from that). Not sure how easy it is tbh. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: Do not distribute files in python_PYTHON primary?
On 19/11/2012 08:55, Nate Bargmann wrote: > Is there a way to use the python_PYTHON primary but not distribute the > file(s) in its list? nodist_python_PYTHON should do the trick -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: AM_CFLAGS no longer in the manual
On 09/12/2012 17:32, NightStrike wrote: > It's not more fully documented elsewhere, though. AM_CPPFLAGS right > about it is, however, fully documented right in this section. This > should be fixed, since nowhere does the manual say that AM_CFLAGS is > "-g -O2" by default. Is it? I was confident that AM_CFLAGS is unset by default, but CFLAGS (from autoconf) is "-g -O2" by default. And no you shouldn't change CFLAGS in configure.ac, please. That's an user-assignable variable, distributions cry every time that we have to patch a CFLAGS="$something" in configure.ac. Especially when that's to set/unset -O and -g flags depending on a debug/release build (hint: distributions want debug information with optimized builds as well!). -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: AM_CFLAGS no longer in the manual
On 09/12/2012 23:06, Jeffrey Walton wrote: > Seems reasonable (otherwise a stack trace is useless). Also, it does > not affect performance. Confer: "How does the gcc -g option affect > performance?" http://gcc.gnu.org/ml/gcc-help/2005-03/msg00032.html. Correct. But in Gentoo I had to end up writing an explicit guide about it as people (both upstream developers and users) tend to mix up the two things: http://www.gentoo.org/proj/en/qa/backtraces.xml Unfortunately there are a number of packages that do something like (pseudo-autoconf — I know it's broken) AC_ARG_ENABLE([debug], , [CFLAGS="-O0 -g3 -DDEBUG"], [CFLAGS="-O2 -g0 -DNDEBUG"]) which is a pain for us to manage (and we usually end up removing and just handling the debug handling on our side. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: AM_CFLAGS no longer in the manual
On 10/12/2012 01:20, Jeffrey Walton wrote: > Devil's advocate: what happens when projects start adding a Test > configuration (in addition to Debug and Release)? In Test, things like > private and protected are defined to public so interfaces can be > tested and state asserted? I haven't hit that kind of projects to be honest — I would say they don't fare well into the usual automake configs — and for sure they fit very badly on Gentoo at the very least because tests are ran on the same code that is built for install, by design. I would be surprised if Debian or Fedora support that any better, but I can't refute that myself, so ... -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 28/01/2013 20:48, Stefano Lattarini wrote: > Feedback, opinions, objections? First of all, I would like to hope that this is not going to be rushed through — it's an important and big change and I think having discussion about it with others might be a better idea. One thing that worries me at first thought is how often do you expect a new major version to be out; once an year? twice an year? once every two years? That rate is going to be the one thing that makes or breaks it from an automake consumer prospective I think. Another thing that I think is important, that ties into the versioning scheme even though it's not really part of it would be to make two things cleaner: - what in Gentoo we call "slotting": i.e. the ability to install multiple automake versions in parallel; we have our own wrapper scripts maintained by Mike Frysinger, I think they were originally imported from Mandriva; I'm pretty sure other distributions have other similar wrappers... if instead of everybody having our own, we had a single maintained tool for the job, that would probably be a nice thing; while adding a suffix to the build solves most of the collisions between automake versions, info manuals for instance do not get renamed; - ability for a configure script to check for automake version; yes I know it's not the usually-proposed method to deal with it, but most projects would like to have something like that at this point. Otherwise we end up with m4_ifdef hacks that are just that: hacks. Especially if moving in the direction of multiple major versions, there are packages that would like to have their build system re-buildable on RHEL5 as well the latest Debian or Gentoo, and then they'll end up with nasty hacks, or requiring an older automake version and hope it doesn't cause other issues. Having a way to test whether we're running automake X.Y or later would be nice (and not just export the version value or people will mess up the test for "2.1", I've seen that happen too often for GCC or BerkDB). -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 31/01/2013 13:47, Stefano Lattarini wrote: > But there is already such a discussion going on; see: > > <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578> > > Or did you mean something else? I would expect a more ... visible discussion. Honestly bugs are all nice and shiny but I don't expect most of the automake consumers out there to even know where to find them (debbugs is handy with the email interface, but it's not exactly the nicest way to find and follow bugs, IMHO). I'll probably write a blog post myself about it to get some attention to it. > I think that, with the new freedom the minor versions would give us to > implement new features and do code optimization and refactoring, we could > aim to have a new major version every 18 or 24 months (this too should be > registered in HACKING). Okay that sounds reasonable. I would be more toward 24 than 18 — maybe going for 18 to the next "beta"-quality automake, 24 to the final release. Speaking of which I would suggest that we call X.0 the betas, and suggest general usage only when X.1 is out... > Since the scripts, the data directories and the manual pages are already > versioned (with both major and minor version), adding support for versioned > info pages might be enough to solve this issue. To a point. While it allows the multiple installation it does not help to solve the difference in multiple-automake changing between distributions. My hope would be for something like that to get rid of most of the "try-to-find-automake-version-X" logic in autogen.sh scripts (the moment when autogen.sh scripts can finally DIAF, I'll rejoice). > Then, we might even add a > new option to Automake's configure to ensure only versioned stuff is > installed (that is, no 'bin/automake' link to 'bin/automake-1.13', no > 'man1/automake.1' manapge containing ".so man1/automake-1.13.1", etc), > if that can make packagers' life even simpler. Sounds like a good idea... > Isn't it too late to check for that at configure runtime? You probably > want some m4 macro that let you discriminate between different versions > at automake/autoconf runtime, right? (Your further elaboration below > seem to imply that the answer to this question is "yes"). Sorry I wasn't clear enough, I don't expect it to be found at ./configure time, but rather at autoconf time. So that one can decide whether they want to use silent-rules, dist-xz, serial-tests and so on.. Don't assume that it's easy to install a newer automake on older systems to work during development, because as I noted above, every distribution has its way to wrap automake, and none that I know allows you a decent way to integrate an user-provided version. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 31/01/2013 20:58, Jack Kelly wrote: > IMHO, that seems like a great way to cause trouble for unsuspecting > users. (Anyone remember KDE4.0?) Can you expand on why you think it's a > good plan? Because unlike KDE, automake can put a big fat warning in the generated configure that says "You're using a version unsuitable for production", and then people would understand it much better. KDE 4.0 was a screwup because there was no big fat warning, and users insisted to have it. No user _asks_ for automake. > Is there a system like X.beta1, X.beta2, ..., X.0 that is going to fit > the ordering system for most package managers? Bonus points if it works > in asciibetical order, too. Good luck finding one. Gentoo would be fine with X.Y_betaZ — but I honestly dislike X.Yb because that kind of stuff is usually _after_ X.Y for almost everything but autotools.. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [FYI] {branch-1.13.2} NEWS: we no longer plan to drop $(INCLUDES) support in next major version
On 03/02/2013 20:28, Stefano Lattarini wrote: > > And note that support for INCLUDES has not been re-introduced in the > master branch yet, at the moment of writing; but we plan to definitely > do so before the next major release. Stefano, just to be clear (so I can actually update my forward porting notes as well), INCLUDES is still considered deprecated, right? Is it going to trigger a warning? -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Inconsistencies in boolean parameters
While working on my guide, I've noticed that there is an inconsistency with the way boolean parameters are passed. AM_MAINTAINER_MODE expects [enable] to be on-by-default. AM_SILENT_RULES expects [yes] to be on-by-default. Maybe it's something to keep in mind for future cleanups to accept both forms, and normalize the documentation? -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
AM_MAINTAINER_MODE
On 07/02/2013 16:18, Stefano Lattarini wrote: > (Side note: using AM_MAINTAINER_MODE these days is generally a bad idea > IMHO; we should find a way to deprecate its usage in documentation, and > eventually start warning at runtime if it is used -- and don't worry, > with *no* plans for a later removal!) I would argue that it would be nice to have AM_MAINTAINER_MODE([enable]) as default (and that's what I'm going to suggest on my documentation. The reason is that while it makes total sense for developers and users alike, it's a pain for package maintainers, as sometimes timestamps end up mangled by patches, and we get unexpected maintainer-mode rebuilds... especially for source-based distribution like Gentoo, we have to be wary about maintainer mode as it would make different users end up with different versions of the build system... -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: AM_MAINTAINER_MODE
On 07/02/2013 19:47, Stefano Lattarini wrote: > So you want to allow users to disable maintainer-mode rules in every > package? Yes. Where users here is "distribution packagers". > Better risk an extra rebuild than to miss a required one IMVHO. Or > understand why timestamps get mangled, and fix that problem instead of > its symptoms (i.e., unnecessary rebuilds, in this case). Yes and no. In some cases, the problem we get is that the rebuild only happens in some circumstances, and thus the developer is missing it, but it happens on the users' systems, and then they report a bug that we can't reproduce... Basically, I want to have a build failure rather than a build that might be wrong. > I failed to understand what you're saying here, sorry. Care to rephrase, > or give an example? I don't have an example at hand, but let's say this: - you got a package that for whatever reason is completely messed up if generated with automake-1.12, but works fine with 1.9; - when I'm rebuilding it as part of an ebuild (Gentoo's spec files equivalent, give or take), I declare WANT_AUTOMAKE=1.9; - but I'm not rebuilding it in the ebuild; - until I get a patch that I don't check thoroughly and messes up the timestamps; - I still do not rebuild autotools in a controlled fashion; - automake triggers the rebuild, and rebuilds with 1.12; - I'm screwed. Variations can happen if for instance the configure relies on a variable that is not declared with AC_ARG_VAR (way too common). Yes, it's all solvable with more attention to details and similar, but since we care for stuff to at least behave, --disable-maintainer-mode is much nicer _to us_. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: AM_MAINTAINER_MODE
On 08/02/2013 13:26, Stefano Lattarini wrote: > But maintainer-mode won't help you here; it will just cause make to ignore > some remake rules that require maintainer tools, so you are *more* likely > to end up with a subtly and silently broken package (or at least one that > is in an inconsistent state). No? Definitely not inconsistent: it'll be consistently messed up in the same way. > (Aside: No it doesn't; if a package has been bootstrapped with 1.9.x, > it will call "automake-1.9" and "aclocal-1.9" in the rebuild rules, > ensuring the correct versions are used, or that the remake fails if > those versions are not available). Sometimes, sometimes not. I've seen it happen, especially for older automakes. I think it might have something to do on whether they were built with a suffix or not, when they made the dist. > But if the patch legitimately modified some Makefile.am, then you are > as much as screwed if you do not re-bootstrap with the autotools in a > controlled fashion nor have the automatic remake rules kick in: the > Makefile will not be regenerated, which might cause build errors (in > the best scenario) or leave the built package in an inconsistent > state. Again, the consistency issue is the other way from what you think: if it always fails, and the patch to Makefile.am always get ignored, it's much more consistent than it sometimes sticking, and sometimes not. For a distribution packager that has to troubleshoot errors, that consistency is gold. > But still, it is conceptually wrong, because it suggests that having > incompletely specified dependencies is a legitimate way to avoid > potentially useless rebuilds due to issues in other tools. It's conceptually wrong that I need to fix every other package because upstream ignores most of the best practices ever said about development, but I still have to deal with it. We have a split here: you want a perfect world where nothing that is conceptually wrong exists; I live in a world where conceptually wrong is daily bread and I want a weapon against time waste. > But OTOH, I certainly do not want to encourage any new use of it: unless > I'm still missing something fundamental here, AM_MAINTAINER_MODE is > basically an hack to work around suboptimal practices or brokenness > in other tools, and we should work toward fixing those rather than > offering brittle workarounds. If that's what you want, fine. Do know that I _will_ fiercely suggest to developers to use AM_MAINTAINER_MODE([enable]) in their configure.ac. It does not make a change by default, but it allows us to have a reproducible build, which is what we really need. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 11/02/2013 15:54, Stefano Lattarini wrote: > But what if we want to have multiple betas for, say, Automake 1.14? Today, > we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme > you are proposing? Given that 1.12.0 was "not really final release", and 1.13.0 _and_ .1 were "not really final releases", I would suggest calling the first beta as 1.14.0 with the big fat warning, then everybody's satisfied (no missing features, for instance), it rolls as 1.14.4 (say) "really final release". This should be more or less equivalent to Apache's versioning, and leads to decency, I'd say. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 12/02/2013 09:26, Stefano Lattarini wrote: >> Given that 1.12.0 was "not really final release", >> > Why not? AM_PROG_MKDIR_P. > This is true, but is only due to the fact that I released them with > too much haste, without giving time for proper testing. IOW, this > debacle has been a fault of mine, not of the naming scheme. True, but it shows a pattern: most people (even developers who get involved in the process, such as Paolo) do not even look at the beta versions.. > I don't see any need for this; everyone knows that a new major release > is more likely to contain bugs and rough edges. (OTOH, this is not > excuse to be sloppy and hastily in the release process as I've been > for 1.13; but avoiding repeating the mistake in the future will only > require more care and attention from the maintainer, and not a change > of policy). True, but a new beta also is also more likely to contain bugs and rough edges... so it's basically the same thing, thus why I'm saying that it should just be the same. Put out the new major at "not stable yet", try it out all around, then make a release to call it stable. > Any link about this? The info I found on Google doesn't seem very > helpful nor relevant. I'm afraid I don't have anything that Google wouldn't have. But at least for 2.2, it was declared stable much later than ".0" if I'm not mistaken. Basically, it would be like making policy that the new major branch is not stable until we say it is.. which is really what we need. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 12/02/2013 17:44, Stefano Lattarini wrote: > Ah, ok, so in the end you already agree that this is a "documentation" > issue rather than a versioning one. Please correct me if I'm wrong! I guess it's a matter of perception. I honestly don't see the point of beta software if nobody's using it, as it would just actually be an alpha for the beta (.0/.1 releases) which then becomes stable (.2+ — sometimes). If we go with a new major version we could have: 2.0.x -> new major, testing branch (let's not call it beta!), all fine but it throws a huge warning at runtime that the branch is not finalized yet and thus that it should not be used for distributed software 2.1.x -> new major, stable branch, micro versions for bugfix only 2.2.x -> new major, new features branch, introduces deprecation warnings for features leaving in 3.0, possibly some opt-in versions of features becoming standard in 3.0. _If needed_ only: 2.90.x -> experimental branch for the upcoming 3.0 testing branch -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: Creating plain Makefiles with automake
On 24/04/2013 00:10, Gavin Smith wrote: > > My question is, is there any interest in this kind of approach? I feel > that it would be a step towards making the GNU build system easier to > use and understand. As a distribution developer this seems to me just yet another hack that is going to cause us great pain in the future if it is found in the wild.. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: Put GNU build system files in a subdirectory?
On 29/04/2013 20:16, Bob Rossi wrote: > Autotools is a great build system. However, after configuring it to > place as many files as possible in a subdirectory, it still takes up > 87.5% of my projects root directory. And? Do you really think that just for the sake of ls output you should mess up with a build system, making distribution packagers cry? Because that's all I see on this list in the past two threads. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: What did AM_ ever do to you?
On 01/05/2013 04:40, Kerrick Staley wrote: > Automake renamed some macros and dropped support for the older versions > (AM_CONFIG_HEADER -> AC_CONFIG_HEADERS and AM_PROG_MKDIR_P > -> AC_PROG_MKDIR_P come to mind). This is bad because it breaks every > single open source project in existence (break ALL the builds), for reasons > that most developers don't want to have to think about (writing code is > fun; worry about how to build it is less fun). Seriously, the impact is not a sbad as you state here. Other changes before that broke many many more build than that. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: automake-1.13.1 install failed
Run `perl-cleaner --reallyall` and fix your Perl install. (Gentoo specific.)
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
On Sun, May 26, 2013 at 2:13 AM, arikuu wrote:
> I have an problem what i don't understand. I had automake-1.13.1 before
> installed without any problem but becaus of few reasons i had to eliminate
> it. And now EVERY version of Automake do this:
> checking for gcj... no
> checking that generated files are newer than configure... done
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating t/wrap/aclocal-1.13
> config.status: creating t/wrap/automake-1.13
> make -j2 APIVERSION=1.13 pkgvdatadir=/usr/share/automake-1.13
> GEN m4/amversion.m4
> CDPATH="${ZSH_VERSION+.}:" && cd . &&
>
> "/var/tmp/portage/sys-devel/automake-1.13.1/work/automake-1.13.1/t/wrap/aclocal-1.13"
> Can't locate
> /var/tmp/portage/sys-devel/automake-1.13.1/work/automake-1.13.1/aclocal in
> @INC (@INC contains: /etc/perl /usr/local/lib64/perl5/5.16.3/x86_64-linux
> /usr/local/lib64/perl5/5.16.3
> /usr/lib64/perl5/vendor_perl/5.16.3/x86_64-linux
> /usr/lib64/perl5/vendor_perl/5.16.3 /usr/local/lib64/perl5
> /usr/lib64/perl5/vendor_perl/5.16.0 /usr/lib64/perl5/vendor_perl
> /usr/lib64/perl5/5.16.3/x86_64-linux /usr/lib64/perl5/5.16.3 .) at
>
> /var/tmp/portage/sys-devel/automake-1.13.1/work/automake-1.13.1/t/wrap/aclocal-1.13
> line 29.
> make: *** [aclocal.m4] Error 2
>
> And i don't find any reasons. I am on Gentoo and using Portage
>
> Gratefull of any help
>
>
>
> --
> View this message in context:
> http://gnu-automake.7480.n7.nabble.com/automake-1-13-1-install-failed-tp20533.html
> Sent from the Gnu - Automake - General mailing list archive at Nabble.com.
>
>
Re: Help with static linking
On Fri, May 31, 2013 at 2:31 PM, Robert Boehne wrote: > -Wl,-static -lzzip -Wl,call_shared > > I don't have a computer in front of me, so YMMV, you should man ld to make > sure those flags are correct. > What you're thinking of is -Wl,-Bstatic and -Wl,-Bdynamic — for the GNU linker at least, but this is not portable. Seriously, it sounds to me like something else is wrong, you should never have the need to statically link stuff that way unless you're doing release management of binary applications, in which case you have another set of problems entirely. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: Conditional variable based on silent or not silent?
On 08/06/2013 12:58, Nate Bargmann wrote: > > As 'make V=1' can be used to override the silent rules created from > 'configure', is it possible to write the variable with the ability to be > conditional at make time? In other words, does make set some sort of > environment variable that I can test for to set my variable? If not, I > am comfortable with quieting Swig manually. I think you're missing the point of silent rules. Silent rules do not silence the compiler's warnings, but are rather designed so that _exactly those_ warnings are easier to notice... -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: aclocal and AC_CONFIG_MACRO_DIR
Hi Werner, AC_CONFIG_MACRO_DIR expects a single directory (it's used by among other libtool to put its m4 files). AC_CONFIG_MACRO_DIRS is the one you want to use (plural form). HTH Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Fri, Jun 21, 2013 at 7:27 PM, Werner LEMBERG wrote: > > [automake 1.14] > > It seems that there are problems if AC_CONFIG_MACRO_DIR contains more > than a single directory. Calling > > aclocal -I gnulib/m4 --force -I m4 > > within the attached bundle causes > > aclocal: error: couldn't open directory 'gnulib/m4 m4': > No such file or directory > > If I comment out the lines > > AC_CONFIG_MACRO_DIR([gnulib/m4 >m4]) > > the call succeeds. > > > Werner > > > PS: Sorry for not sending a minimum example, but I don't have enough > time to work on that. >
The deprecated/undeprecated macros and variables
Hi all, Stefano what is the current situation/plan for the stuff that was deprecated and then undeprecated between automake 1.13 and 1.14? I refer in particular to AM_PROG_MKDIR_P, AM_PROG_CC_STDC and AM_CONFIG_HEADER macros, and the INCLUDES variable. Are they planned for removal in 2.0 now? Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: libtool libraries requiring other libraries
Okay, Robert already answered but... On 16/07/2013 15:56, Steffen Sledz wrote: > FOO_LDFLAGS="-L$with_libfoo_path/lib -lfoo" [...] > progbar_LDFLAGS = $(FOO_LDFLAGS) This is simply wrong, whether or not it works after adding LT_INIT. -lfoo is a library not an LDFLAG. It should be passed to _LDADD not to _LDFLAGS. What happens is that if you pass it as LDFLAGS it's going to be _preprended_ to the list of object files, and linkers set to link only needed libraries will ignore it altogether. Don't misuse LDFLAGS please. It just becomes a pain in the neck for distributions. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: Issues with subdir-objects and differing versions of automake
On Mon, Aug 26, 2013 at 3:30 PM, Shawn Webb wrote: > clamd_SOURCES = \ This is just a guess because I can't look at your repositories right now, but I would suggest bringing the declaration of clamd_SOURCES *outside* the conditional, that might fix the make distclean. I would also argue for just using non-recursive automake, but it might be the least of your problems for now. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: What does subdir-objects do?
On Sat, Aug 31, 2013 at 11:36 PM, Kerrick Staley
wrote:
> git checkout with-subdir-objects
> git clean -dfx
> ./autogen.sh
> make
> find . > /tmp/with-subdir-objects-tree
> git checkout without-subdir-objects
> git clean -dfx
> ./autogen.sh
> make
> find . > /tmp/without-subdir-objects-tree
> diff /tmp/with{,out}-subdir-objects-tree
>
> The diff found 0 different lines, so I guess I'm missing something. What
> exactly does subdir-objects do?
>
You're using git submodules, so your git clean -dfx is not working properly.
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: problem with subdir-objects and not found .Plo files when migrating to 1.14
On Sat, Aug 31, 2013 at 11:50 PM, Sergey 'Jin' Bostandzhyan < j...@mediatomb.cc> wrote: > > Is it possible to keep the logic with the in-tree build directory with > automake 1.14? I did try to move all the logic from build/Makefile.am into > the top level Makefile.am and removing build/Makefile.am completely, but > it does not help - .Plo files are not found. I'd say it's a very bad idea to use that build/Makefile.am. Move the includes on the top-level Makefile.am, and get rid of $(top_srcdir) on all the _SOURCES declaration and it should work fine. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: problem with subdir-objects and not found .Plo files when migrating to 1.14
On Sun, Sep 1, 2013 at 10:36 PM, Sergey 'Jin' Bostandzhyan wrote: > I wonder why the authors of automake would try to restrict different and > actually valid usage scenarios? I've been using this setup for over 5 years > in different projects, I'd be really disappointed if I had to switch to a > setup that is much more inconvenient for me. > Because trying to be clever and special with build systems is a bad way to make a build system. Distributions will dislike you and it's much less likely that they'd like to package your software. If I were to find any problem with the build system of your project, I would stop looking the moment I find the silly "build" directory, and decide that it's not worth packaging at all. Don't be special, don't be clever. Use out-of-tree build if you want and behave consistently with other projects. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: problem with subdir-objects and not found .Plo files when migrating to 1.14
On Sun, Sep 1, 2013 at 11:27 PM, Sergey 'Jin' Bostandzhyan wrote:
> Interesting opinion, however, just an opinion and not a fact.
>
An opinion of a distro packager who's been dealing with similar stuff for
years...
> I've been
> using the same "build" approach in MediaTomb and we got packaged for almost
> all available distros. Not once have I heard complaints about the build
> directory, and why should I anyway? Packagers don't care about things like
> that as long as "make install" works properly and respects ${prefix}.
>
You have a very naïve idea of how packaging works. And if you didn't hear
any complain it means you haven't listened very carefully. Given I actually
was the original packager for mediatomb for Gentoo, and that I did so
because there was no alternative, I'm pretty sure I know what I'm talking
about. It's not a coincidence that I dropped it quite quickly.
> Well, so far I have not heard a single technical argument on why I should
> not be doing things that way.
>
> "Very bad idea" and "don't be special" qualify for arguments of personal
> taste,
> and that's what I love Linux for: it gives you the freedom to do things the
> way that is most productive to _you_. Actually, if noone was ever clever
> and
> special we'd probably be using MS DOS.
>
Yadda yadda. You haven't given a technical argument for your choice either.
It's just aesthetics and convenience for your make command. While on the
other hand you have consistency for the people that cater your software to
users.
You want technical? As you can see by the warnings issued by automake 1.14,
non-subdir-objects build are going to go away at some point because they
require much more maintenance than it's worth, just because of aesthetics,
isn't that enough? I would also add that you're trying to be clever with a
build system while not really groking it, which is more than dangerous.
Good luck, but definitely I'll mark down your project as a "do not go
near". I've had enough headaches with mediatomb.
Re: Problem with circular dependencies
On Sun, Sep 15, 2013 at 7:16 PM, Jules Colding wrote: > > So, how do I tell the top-level Makefile.am that it should traverse all > sub-directories building only the libraries, and then traverse the > sub-directories again building only the test applications? > You don't. This is one of the reasons why you shouldn't be using recursive makefiles... Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: automake breaks my file by putting includes after rules; how do I fix this?
On Wed, Nov 20, 2013 at 9:33 PM, Jason Gross wrote: > (I don't want to require running autoreconf and > configure whenever you add a file that the makefile already knows how to > compile). > You actually do not need autoreconf. Maintainer mode will take care of it for you buy only running automake, and running the config status updater. So use maintainer mode, and don't be a snowflake, please. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: only installing shared versions of some libs
That's not the correct way to do that. Yes, libtool is a prerequisite and you need -shared, but it should be in _LDFLAGS. But more importantly you want -module and -avoid-version. My Autotools Mythbuster guide has a section dedicated to building plugins: https://www.flameeyes.eu/autotools-mythbuster/libtool/plugins.html Have fun. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Tue, Dec 10, 2013 at 10:02 AM, Václav Zeman wrote: > On 10 December 2013 09:47, Daniel Pocock wrote: > > > > > > I've recently adapted a project to support DSO plugins/modules > > > > The existing project includes normal libraries and binaries. In a > > normal build, we want to > > > > a) build and install the shared and static versions of the normal > libraries > > > > b) only install the shared versions of the plugins > > > > I don't mind whether static versions of the plugins are built (we don't > > currently use them) but I would prefer that "make install" does not > > install them > > > > Can anybody comment on the best way to do this? The Makefile.am is > > linked from here (repro/plugins/example/Makefile.am): > > > > http://list.resiprocate.org/archive/resiprocate-commit/msg07875.html > > This is completely untested suggestion: > > I am assuming you are using Libtool as well. Given the Libtool[1] and > Automake manuals, I think it might be possible to do what you want by > modifying libexample_la_CXXFLAGS (or similar appropriate) variable to > add Libtool's -shared flag, which, I think, should/could do what you > want. > > [1]: > http://www.gnu.org/software/libtool/manual/html_node/Compile-mode.html#Compile-mode > [2]: > http://www.gnu.org/software/automake/manual/html_node/Libtool-Flags.html > > -- > VZ > >
Re: Can't include SQLite libs in compile
On Wed, Dec 18, 2013 at 9:26 PM, Jordan H. wrote: > Makefile.am: > > program_CFLAGS += @SQLITE_CFLAGS@ > program_LDADD += @SQLITE_LIBS@ > First you should not need to use AC_SUBST() for these variables at all if you have the right pkg.m4. Second, can you please post the full Makefile.am? If you haven't defined program_LDADD and program_CFLAGS before using += they are not going to work. Third, you want to use $(SQLITE_CFLAGS) rather than the @@ replacement. A bit of documentation for PKG_CHECK_MODULES can be found on my Autotools Mythbuster: https://www.flameeyes.eu/autotools-mythbuster/pkgconfig/pkg_check_modules.html Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: Can't include SQLite libs in compile
On Wed, Dec 18, 2013 at 10:55 PM, Jordan H. wrote: > myprog_LDFLAGS = `pkg-config --libs sqlite3 gmodule-2.0` > myprog_LDFLAGS += -Wl,-export-dynamic > Don't use _LDFLAGS for libraries, it's broken and may not work depending on your distribution's configuration of the toolchain. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: Getting files in /lib/udev/rules.d with Makefile.am
You want to use pkg-config to get the right directory to install to, and make it a new install class dnl configure.ac PKG_CHECK_VARIABLE(udevrulesdir, ...) (or whatever the name is of the macro, I forgot) # Makefile.am udevrules_DATA = foo.rules. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 14 March 2014 18:33, Paul Richards wrote: > Hello, I have a package I am working on and was wondering how to get my > udev rules file into the directory /lib/udev/rules.d, if there is a > variable > substitution for the /lib directory. I found the macro $(libdir), but on > debian this expands to /usr/local/lib which does not work for udev on > debian. > > > Any help is greatly appreciated! > > Thanks, > > Paul Richards
Re: Cannot locate /usr/share/aclocal/pkg.m4
That is part of the pkg-config-devel (or however it's called) package, not automake. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 25 March 2014 22:41, Yunzhong Gao wrote: > Hi all, > I was trying to install automake 1.14 on Ubuntu 13.10 which comes with > automake 1.13 pre-installed. I appear to be missing this file > /usr/share/aclocal/pkg.m4. Is this file > auto-generated by the configure-make-install process, or is it to be > downloaded from > somewhere? Many many thanks in advance, > - Gao >
Re: appending LDADD to prog_LDADD
That is indeed the correct way to handle it. Given I know Stefano is unlikely to have time any time soon, I think patches will be welcome but may linger for a while :) Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 26 March 2014 08:15, Daniel Pocock wrote: > > > I understand from the docs that specifying prog_LDADD will override > LDADD (and the same for prog_CPPFLAGS, ...) > > http://www.gnu.org/software/automake/manual/html_node/Linking.html > > If it is desired to merge prog_LDADD and LDADD, is there any recommended > or preferred solution? > > I've tried > > LDADD = -lfoo > LDADD += -lrt > > prog_LDADD = -lfoo $(LDADD) > > and it seems to work for me - if this is the way to go, could it be > included in the manual page perhaps? > > > > > >
Re: [NEWBIE] How do you make a library w/libtool
Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 6 September 2014 13:50, Arthur Schwarz wrote: > I've successfully made a executable version of my software and am trying to > make a library, right now as a UNIX library and soon using libtool for a > dynamic library. The static library does not work and I don't see an error > message. It seems to configure correctly (using autoreconf) but no *.gz > file > is generated. I can't figure what's wrong and can't go to generating a > dynamic library until I do. > Why are you expecting a .gz file at all?
Re: [NEWBIE] How do you make a library w/libtool
I think you're definitely misunderstanding how the tools fit together. Only `make dist` will generate a `.tar.gz` distribution of your sources, not `autoreconf` at all. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 7 September 2014 00:06, Arthur Schwarz wrote: > > Diego; > > ____ > > > > Diego Elio Pettenò — Flameeyes > flamee...@flameeyes.eu — http://blog.flameeyes.eu/ > > On 6 September 2014 13:50, Arthur Schwarz wrote: > I've successfully made a executable version of my software and am trying to > make a library, right now as a UNIX library and soon using libtool for a > dynamic library. The static library does not work and I don't see an error > message. It seems to configure correctly (using autoreconf) but no *.gz > file > is generated. I can't figure what's wrong and can't go to generating a > dynamic library until I do. > > Why are you expecting a .gz file at all? > > Good question. What I’m using the auto tools for is to generate an > exportable configuration compatible with GNU. My assumption is that > autoreconf will generate a *.gz file if there are no errors. This seems to > work when I create an 'executable' configuration and seems not to work when > I create a library. When the library version works I intend to use > libtools. > > > If my understanding is wrong could you provide guidance? > > >
Re: Auto-Generating ChangeLog and AUTHORS for projects in a version tracking system?
Can't we just say that gnu-flavour automake is pointless and foreign should be the default? Or am I too opinionated on that? Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 29 October 2014 15:27, Arne Babenhauserheide (IMK) < arne.babenhauserhe...@kit.edu> wrote: > Dear GNU Hackers, > > > In quite a few guides I saw people suggest using the foreign automake > style to avoid having to create the required text files. > > The goal of this email is to get more people to use the GNU style, so > the interface for understanding an autotools project becomes more > consistent again: GNU style should become standard for all guides. > > > Among the required files, NEWS is easy to create but cannot be guessed > automatically because it is intended for humans, and README is becoming > standard (again) due to most code hosting sites using it as the summary > page. AUTHORS and ChangeLog normally only contain information which > already available in most version tracking systems - and can be created > easily from that. > > If autotools did this automatically, the barrier for using GNU style in > the autotools with a version tracking system would be much smaller: Just > write README and NEWS. > > > I initially planned to just send a small example script, but that > matured faster than I had expected, so you can now find it at > > > > https://bitbucket.org/ArneBab/autochangelog/src/tip/create-or-update-changelog-and-authors.sh > > If someone with git-foo could cleanup the git ChangeLog creation to > conform with the GNU ChangeLog standard, that script should be a good > working example. > > The script only touches files which were created by the script or are > missing. > > > Best wishes, > Arne > > PS: I initially sent this mail to the autoconf list. The original > discussion is at [1] and includes the gnulib script which roughly does > for git what I propose here. Doing this in automake would have the > advantage that all users benefit from the lower barrier of entry to the > consistent GNU style. > > [1]: http://lists.gnu.org/archive/html/autoconf/2014-10/msg0.html > > -- > Doktorand > Gruppe: GHG > > Raum: 435/410 > Tel.: +49 721 608-22885 > arne.babenhauserhe...@kit.edu > > Karlsruher Institut für Technologie > IMK-ASF > Postfach 36 40 > 76021 Karlsruhe > > > >
Re: Auto-Generating ChangeLog and AUTHORS for projects in a version tracking system?
On 29 October 2014 22:39, Eric Blake wrote: > > [we tend to avoid top-posting on technical lists] Sorry, me sleepy and not paying enough attention. > > > Can't we just say that gnu-flavour automake is pointless and foreign should > > be the default? Or am I too opinionated on that? > > For GNU projects, the 'gnu' flavor still makes sense, even if it could > use a little modernization such as easier automation of generating > ChangeLog from version control. And while these days, automake is > probably used by more non-gnu projects (where 'foreign' may make more > sense) than GNU projects, that's still not a good reason to toggle the > default. I like what the GNU Coding Standards represent, and deviating > from them deserves a mention in configure.ac to make it apparent that > you thought about it. All good and well, but then I may have misunderstood Arne's original point. If he's trying to get the GNU style to be "good enough" for more projects, I think that's a moot point because as you said most projects use it outside of GNU, and they would probably still find enough issues with it that they wouldn't use it — and they would probably still complain about bad autotools doing bad things because they copy-paste from the wrong project. If we're talking of making life easier for GNU maintainers, I have no opinion because I have no stakes on the matter at all. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: Auto-Generating ChangeLog and AUTHORS for projects in a version tracking system?
On 30 October 2014 06:45, Arne Babenhauserheide (IMK) wrote: > Am 30.10.2014 00:43, schrieb Diego Elio Pettenò: > I don’t want to change the GNU style. I want to have an easier way to > *adhere to* the existing GNU style by providing default tool support for > creating the ChangeLog and AUTHORS file from versiontracking systems. Great. But people don't *want* to adhere to the GNU style, most people just end up creating 0-sized AUTHORS NEWS and ChangeLog files, because otherwise automake fails, and then they complain about autotools being messy and requiring useless boilerplate. > Additional motivation for this: If I want to teach someone to switch > from a simple Makefile to autotools, I have to talk about https://autotools.io/whosafraid.html For 90% of the non-library projects out there this will cover enough that is needed to start. > As you can see, how to write a conforming ChangeLog takes roughly as > much explanation as writing the configure.ac. And every new contributor > will have to learn how to do that (while the other topics are only > needed for the initial setup or for the maintainer). So here is the usual disagreement. I don't like GNU style and I think that imposing it and wasting people's time on it is not worth it at all. Again I don't have stakes on the gnu style because I don't use it. I don't want to use it. And I don't want to force anybody else to use it. I usually make people happy when I tell them you can use automake in foreign mode because then there is no 0-sized top-level file there just to make it happy. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: Auto-Generating ChangeLog and AUTHORS for projects in a version tracking system?
On 30 October 2014 09:55, Arne Babenhauserheide (IMK) wrote: >> Great. But people don't *want* to adhere to the GNU style, > > Do not want to adhere to the GNU style or do they not want to bother > with creating the files? There is a very important difference in > motivation: People from the first group get what they want with foreign > style. People from the latter group however would be happy to use GNU > style, if it did not create additional work for them. The problem is that it does, given that GNU style is not the presence of those four files or not, but also involves the portability warnings and further limitations designed for the GNU project, that they most likely won't care about. I get it, you want to get them to see the Light of GNU. But I'm not there to indoctrinate on the style of ChangeLog people need to use, I'm there to get people a working build system that does not drive packagers crazy. > This change is for the latter group, since the former group can already > switch to foreign style by just adding a single parameter. Thus why I'm saying I don't care. If you want to do that for the GNU people I don't care, I just think it's a false assumption that people won't be complaining about another of the GNU style rules at some point. > Autogenerating the AUTHORS and ChangeLog would reduce this to a single > 0-sized file, because nowadays most people understand that a README is > important -- I think the same will happen for the NEWS file, once code > hosting platforms start using the NEWS file as source to provide > human-readable news about projects. Then this would eliminate the > 0-sized files. Err, no. I mean no really. Autogenerating them may help sure, but I don't think "people understand a README is important" — people get *forced* to understand a README is needed, but for instance I wouldn't use gnu style anyway because I call my file README.md so that GitHub at least *renders* it correctly. So yeah, I still expect 0-sized files all around. > Note: Here you note that autotools need COPYING, > but this is created automatically nowadays. > You only need to provide it if you don’t want to use the GPL. Which once again I'm not assuming people do. Because I've seen packages in which the README and the source says MIT, but then they got a default GPL COPYING in there. Which is bad, and I hope I don't have to explain to you how and why. Again, carry on, it can't make things worse but I'll still suggest people to stay away from gnu style unless they are part of the GNU project. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: converting to subdir-objects
On 8 March 2015 at 09:46, Harlan Stenn wrote: > foo_SRCS = ... $(srcdir)/../foo/bar.c > Have you tried omitting $(srcdir) altogether? It should work just fine then. So just foo_SOURCES = ../foo/bar.c Diego Elio Pettenò — Flameeyes https://blog.flameeyes.eu/
Re: Setup for a project with autotools so resulting executables can see required binary files?
On 14 March 2015 at 16:10, Jamil Egdemir wrote: > I'm using c to work on some code building against allegro and using > autotools to handle the build system. Trouble is the code is trying > to pull in a bitmap and I'm not sure how to handle this properly when > using autotools. (My apologies in advance if this is more of a c > question or I'm posting on the wrong list here.) > This is indeed mostly a general programming question more than one about autotools, but anyway. You're not fully-qualifying your image path, which means you're going to load it from CWD (Current Work Directory), and that of course will fail if you're not in the same directory as the bitmap file. You can install the data file as `data_DATA = yourbitmap.bmp` and then use `DATADIR "yourbitmap.bmp"` to load it, in which case it will only work if you're installing the package and not if you're building and running it locally. Diego Elio Pettenò — Flameeyes https://blog.flameeyes.eu/
Re: The right way to use standard variable in configure.ac
As John said you should use
CPPFLAGS="${CPPFLAGS} -DMACRO1 -DMACRO2"
But most likely you want to set this in DEFINES rather than CPPFLAGS,
or use AC_DEFINE directly…
Diego Elio Pettenò — Flameeyes
https://blog.flameeyes.eu/
On 3 April 2015 at 00:04, Andy Falanga (afalanga) wrote:
> Hi,
>
> I placed the following in my configure.ac file:
>
> CPPFLAGS="-DMACRO1 -DMACRO2"
>
> because I found that as an example on a webpage someplace. I reviewed so
> many learning about the autotools that I don't recall which one now. I did
> this because there were some preprocessor flags that I wanted to have common
> to all sub-makefiles.
>
> I ran into a problem today, however, where I needed to add a -I directive to
> my CPPFLAGS in order to find the necessary headers. Then, the problem
> stepped in. Because I placed this line in configure.ac, it was transcribed,
> verbatim (as it should), into configure. The net result: not matter what I
> placed on the command line was ignored. For example, the following:
>
> CPPFLAGS=-I/path/to/the/alternate/location ./configure --build=x86_64-linux
> --host=arm-poky-linux-gnueabi
>
> The additional path wasn't being appended, it was being stomped. Did I miss
> a macro? How should this be done because, obviously, I've gotten it
> incorrect.
>
> Thanks,
> Andy
