Ralf Corsepius wrote:
On the opposite side, all automake+autoconf based packages applying
mixed case package names have the potential to be be affected. Those
which additionally apply gettext would almost for sure be affected.
A rough estimate from grep-ing the package names of the 2000
Peter Eisentraut wrote:
Akim Demaille writes:
In fact, I think all the tools should provide some --clean. For
instance, the hair we have to clean the Texinfo related files have
nothing to do in Automake. It should be provided by texi2dvi and the
like.
But where does it stop?
I've implemented that myself, but only using autoconf,
not automake. I'd be happy to post a description if
it's of interest. The basic idea is to make sure
all variables are fully qualified so there are no clashes
between any Makefile fragments in the whole system.
(I also prefer to avoid
IMHO the mailing list should reject messages from nonsubscribers.
I thought it already did.
As Justin points out, this is standard operating practice these days.
Accepting posts from strangers just encourages the spammers.
And I'm tired of the 'rape sex' and 'animal action' subject lines and
The Right Way to do this is to include all the
subdir makefile fragments into one big happy
make; then no special locking is needed.
(A la recursive make considered harmful.)
Boy, that's a big change, though.
- Dan
-Original Message-
From: Harlan Stenn
To: [EMAIL PROTECTED]
Sent:
One more try, this time with the attachment.
- Dan
-Original Message-
From: Dan Kegel
To: 'Harlan Stenn '; Dan Kegel
Cc: ''[EMAIL PROTECTED] ' '
Sent: 5/17/2002 11:40 PM
Subject: RE: Parallel builds and SUBDIRS
Yep, I've implemented a build system with that property recently.
I
Russ Allbery wrote:
Eric Siegerman [EMAIL PROTECTED] writes:
-1. I'd *much* rather that automake use the Perl it was configured with
(and subsequently regression-tested with) than whatever random Perl some
user happens to have stuck first in their path.
I agree. Users sometimes have
Thien-Thi Nguyen wrote:
sounds about right -- finding the appropriate mux point to pinch is indeed the
first step towards sanity. if you get funding, give me a buzz. otherwise, i
will continue to work w/ (old) librx and approach the problem from the guile
perspective. (e.g., below is lex.test
Paul Eggert wrote:
From: Eric Lemings [EMAIL PROTECTED]
Date: Thu, 7 Nov 2002 14:23:28 -0700
After reading through Section 11.4 of the Automake Manual, I was just =
curious about how well future releases of Automake (and Autoconf) are =
going to support distributions with Java source code. Just
Hi all,
I'm running a test suite on an underpowered machine, and want to
have test results automatically annotated with how long each one took.
Some of our tests are gtest based, and those already do what I want, e.g.
[ OK ] RecentServerOnly.FailedPermissionize (43 ms)
A quick hack to my
On Thu, Sep 20, 2012 at 11:06 AM, Too, Justin A. t...@llnl.gov wrote:
The goal, however, is to simply distribute a single executable that is
linked with 1) the project's core shared library, and 2) Boost.
Can you simplify it further?
e.g. why have a core shared library,
can you have a core
Justin,
There's a lot of naysaying going on here, but don't assume that a single
properly built binary can't be made to run on a large number of systems
until you've looked into it carefully. All you have to do is target the
lowest common denominator, and statically link anything that isn't
I don't understand automake's make dist support, and could use a clue.
I've boiled my problem down to the following tiny test case, in which
./configure; make works, but make dist fails. It seems that
make dist is unable to follow vpath. Is this a known problem?
To reproduce the problem, do
On Mon, Oct 22, 2012 at 2:21 PM, Paul Davis paul.joseph.da...@gmail.com wrote:
I've never seen a line like this and it looks to be the part that's
not working. The first thing I'd try is to move george.c to
pathprob/foobar/george.c and if that works, either put sources next to
this Makefile.am
On Mon, Oct 22, 2012 at 3:12 PM, Paul Davis paul.joseph.da...@gmail.com wrote:
It doesn't quite solve the problem in my real world situation;
make dist didn't copy #included files, and I needed to add something like
EXTRA_DIST = foobar
to pathprob/Makefile.am.
This is to be expected, you
On Tue, Oct 23, 2012 at 9:05 AM, Rudra Banerjee bnrj.ru...@yahoo.com wrote:
I don't know if this is asking too much from autotools, but is it anyway
possible to install missing dependency files via autotools?
say, in my program, I use libsoup as
#include libsoup/soup.h
is it possible for
In the past, i found it best to make myprojectexe use myprojectlib in
place, without an installiert step inbetween.
Am 09.12.2012 22:28 schrieb Germán Diago Gómez germandi...@gmail.com:
Hello all,
I don't know if this is the correct mailing list to ask because it's a
question that affects
On Mon, May 6, 2013 at 12:10 PM, Martin Kalbfuß ma.kalbf...@web.de wrote:
My program needs Data. So I pass in the data path with my CPPFLAGS.
But that's the path when installed. So I have to install my app first before
I can test it.
Can you make your app be more flexible about where it finds
On Thu, May 30, 2013 at 10:30 PM, Kip Warner k...@thevertigo.com wrote:
The ones for certain I know I should be able to statically link against are
at least libzzip and libpng.
You have
PKG_CHECK_MODULES([libzzip], [zziplib], [have_zzip=yes], [have_zzip=no])
Have you seen
On Sat, Jun 1, 2013 at 4:42 PM, Kip Warner k...@thevertigo.com wrote:
$ pkg-config --libs zziplib
-Wl,-Bsymbolic-functions -Wl,-z,relro -lzzip -lz
$ pkg-config --static --libs zziplib
-Wl,-Bsymbolic-functions -Wl,-z,relro -lzzip -lz
Aw, foo. I was under the
On Thu, Aug 8, 2013 at 2:39 PM, Eric Dorland e...@debian.org wrote:
Previously I would upgrade the automake package to the latest version
and add a new binary package for the previous version. So, for
example, if automake was at version 1.10 and 1.11 was released
upstream I would update the
On Thu, Aug 8, 2013 at 4:43 PM, Eric Dorland e...@debian.org wrote:
That sounds kind of risky, promises of compatibility notwithstanding.
Can you elaborate why?
No. I'm just being paranoid. But there is good precedent for
paranoia being the right setting in matters of backwards
On Tue, May 5, 2015 at 9:41 AM, Andy Falanga (afalanga)
afala...@micron.com wrote:
I am wondering what techniques are considered most useful for managing
multiple installation of versions. For example, my team produces a C++
library which we provide both a C++ and a python API. A couple of
I don't know what you're trying to make, but you could
try cleaning the directory to remove stale symlinks first...
or unpacking the source tarball into a clean directory
and building there.
Here's the code you're probably hitting, fwiw:
```
# Install the missing file. Symlink if we
And of course there's always meson + ninja, which are together rapidly
becoming the clear choice for new projects...
Meson is a candidate for such a next-gen config system. It is in python,
which does not quite qualify as usable during early uplift/bootstrap, but
there are C ports in progress, see e.g. https://sr.ht/~lattis/muon/
In the meantime, I agree that find is more portable than cards ;-)
- Dan
Daniel
FWIW, commandline length limits are a real thing, I've run into them
with Make, CMake, and Meson.
I did some work to help address them in Meson, see e.g.
https://github.com/mesonbuild/meson/issues/7212
And just for fun, here's a vaguely related changelog entry from long
ago, back when things were
Frysinger wrote:
>
> On 15 Feb 2022 20:25, Jacob Bachmeyer wrote:
> > Dan Kegel wrote:
> > > Meson is a candidate for such a next-gen config system. It is in python,
> > > which does not quite qualify as usable during early uplift/bootstrap, but
> > > there
28 matches
Mail list logo
