g 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ò — Flameey
/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/
he 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 co
sh 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/
oo 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 rea
ibraries as well).
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
ages using
autoconf-2.1 than we still have right now....
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
east 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/
ly 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/
ugh 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
d 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
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/
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 El
atures 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ò — Flame
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/
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/
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/
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
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 E
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/
omething" 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/
NABLE([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/
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/
r 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).
-
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/
, 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 b
e 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/
ccept both
forms, and normalize the documentation?
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
, 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
nfigure 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/
ess
> 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 defaul
ivalent to Apache's versioning, and leads
to decency, I'd say.
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
ically, 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/
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/
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/
ould 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/
n 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
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
>
r 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.
gt; 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
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
?
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
the neck for
distributions.
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
rgue 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/
gt; /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.
kefile.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 wo
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 con
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
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/
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/
tools-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
ameeyes.eu/autotools-mythbuster/pkgconfig/pkg_check_modules.html
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
of the toolchain.
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
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
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
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
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
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 Sc
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...
h 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/
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
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/
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/
u're installing the package and not if you're building and running it
locally.
Diego Elio Pettenò — Flameeyes
https://blog.flameeyes.eu/
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:
&
65 matches
Mail list logo
