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. J
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 Ma
On Thu, Sep 20, 2012 at 11:06 AM, Too, Justin A. 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 static library
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
compat
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, d
On Mon, Oct 22, 2012 at 2:21 PM, Paul Davis 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 or move the guts of it
On Mon, Oct 22, 2012 at 3:12 PM, Paul Davis 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 have to tell autoto
On Tue, Oct 23, 2012 at 9:05 AM, Rudra Banerjee 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
>
> is it possible for autotools to install libsoup i
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" :
> Hello all,
>
> I don't know if this is the correct mailing list to ask because it's a
> question that affects both autoconf (for
On Mon, May 6, 2013 at 12:10 PM, Martin Kalbfuß 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 data?
e.g. chec
On Thu, May 30, 2013 at 10:30 PM, Kip Warner 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
https://bugs.freedesktop.org/show_bug.
On Sat, Jun 1, 2013 at 4:42 PM, Kip Warner 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 misapprehention
On Thu, Aug 8, 2013 at 2:39 PM, Eric Dorland 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 automake packa
On Thu, Aug 8, 2013 at 4:43 PM, Eric Dorland 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 compatibility.
> If the
On Tue, May 5, 2015 at 9:41 AM, Andy Falanga (afalanga)
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 our
> consumers thi
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
15, 2022 at 7:52 PM Mike 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,
That's a really good idea. Automake and Autotools in general underpin a
fair amount of key open source software, but is taken for granted.
Ideas for making the case for funding: identify...
- how many commonly used Debian/Ubuntu/Alpine packages and/or GitHub
projects rely on automake/Autotools
-
Does automake have a policy on when to stop supporting a CPU, operating
system, or compiler?
I am pondering the size of the matrix of supported operating systems, cpus,
and compilers, and wonder where a policy like
"Automake drops support 20 years after the release of a CPU, operating
system, or c
Oh, ok, perhaps I was confused by the note in automake 1.13.1's NEWS file
(iirc), which said
Support for IRIX and the SGI C/C++ compilers will be removed in
Automake 1.14: they have seen their last release in 2006, and SGI
is expected to retire support from them in December 2013
Did that not
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 >200
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
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 phony
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
anim
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: 5/17/
Yep, I've implemented a build system with that property recently.
I promised to post a writeup here, but haven't gotten a round tuit.
Maybe it would be useful if I posted part of a project that uses
that build system. The basic idea is it's a cross-platform project
that needs to generate code fo
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 sy
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 som
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 w
32 matches
Mail list logo
