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) afala...@micron.com
On 8 March 2015 at 09:46, Harlan Stenn st...@ntp.org 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/
On 30 October 2014 06:45, Arne Babenhauserheide (IMK)
arne.babenhauserhe...@kit.edu 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
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/
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
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/
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
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
On 6 September 2014 13:50, Arthur Schwarz aschwarz1...@att.net 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
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 dan
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 gaoyunzh...@gmail.com wrote:
Hi all,
I was trying to install automake 1.14 on Ubuntu
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
of the toolchain.
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
://www.flameeyes.eu/autotools-mythbuster/pkgconfig/pkg_check_modules.html
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
-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 vhais...@gmail.com wrote:
On 10 December 2013 09:47, Daniel Pocock wrote:
I've recently adapted a project to support DSO
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/
.
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/
-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
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
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
On Sun, Sep 1, 2013 at 11:27 PM, Sergey 'Jin' Bostandzhyan j...@mediatomb.cc
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
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/
Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
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
?
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
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
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ò
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 ari...@gmail.com wrote:
I have an problem what i don't understand. I had automake-1.13.1
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
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/
us great pain in the future if it is found in the wild..
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
.
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
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/
say.
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
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
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
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/
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/
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/
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ò
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
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
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ò
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
, and only one still
open (which I can fix this afternoon):
https://bugs.gentoo.org/show_bug.cgi?id=automake-1.13
While I'm by far not complete with running the tests on our packages,
usually I get much more trouble much faster.
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http
to get our patches
upstreamed, as half the people out there don't care whether we can
rebuild them or not as long as Fedora X does. =_=
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
-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/
-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/
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/
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
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
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/
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/
think it ever worked or could ever work fine.
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
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
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
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/
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/
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/
than we still have right now
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
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/
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/
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
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ò
).
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
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
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
66 matches
Mail list logo
