Why does the 'subdir-objects' option require AM_PROG_CC_C_O?
I think I figured it out - the generated compile rules do something like
$CC -c -o dir/file.o dir/file.c, is that correct? (I don't have a working
test case, this came up on a mailing list earlier.)
This is kind of obscure, though
> Unfortunately, SPAMmers quickly learn how to break through automated
> defenses so that they can simply subscribe to lists. One way or
> another, list servers are simply overwelmed. There seems to be no
> reasonable solution.
The problem here is not that spammers subscribe to lists; these
> More succinctly put, the list server is having trouble reliably reaching
> your machine. Most likely this isn't the list servers problem, it's yours
> due to either sporadic connectivity on your part, or somewhere between the
> list server and you, or sporadic DNS service on your part. If you ha
Please don't use test -e - it is not available in Solaris' /bin/sh.
$ make check TESTS=conflnk3.test VERBOSE=t
make defs aclocal-1.8 automake-1.8
make[1]: Entering directory `/tmp/automake-1.8.3/tests'
make[1]: `defs' is up to date.
make[1]: `aclocal-1.8' is up to date.
make[1]: `automake-1.8'
I have the following in a Makefile.am:
if BUILD_SRC_BEOS_SUBDIR
d_beos = beos
endif
SUBDIRS = $(d_beos)
where BUILD_SRC_BEOS_SUBDIR is from an AM_CONDITIONAL in configure.in.
BUILD_SRC_BEOS_SUBDIR is not defined because I'm not building on BeOS.
The directory structure is
top level
top le
Alexandre Duret-Lutz writes:
> I'm embarassed to announce the release of Automake 1.8.2.
And rightly so ;-)
It fails two tests here on Solaris 9 - acloca14.test and conflnk3.test.
...checking for a BSD-compatible install... /usr/local/gnu/bin/install -c
checking whether build environment is s
> Lars> Not that I'm complaining about this, just want to know
> Lars> what's going on :)
>
> The keyword is AC_CONFIG_AUX_DIR.
Excellent.
Thanks Alexandre and Eric!
I have a software package that includes another package in a subdirectory:
package_a/
...
package_a/package_b/
...
In order to build a standalone version of package_b, I'm running the following
commands to make sure that no auto* generated files reference the parent dir:
cd package_a/pa
Paul D. Smith writes:
> %% Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>
> bf> Per-subdirectory rules and definitions can be added in order to
> bf> significantly reduce the amount of redundant code, and to
> bf> re-enable the capability to usefully override parts of the default
> bf> Make
> >test -n '$(libs)' && for i in '$(libs)'; do ...
>
> I like that one :-) it's about as short as the current way
> to guard against empty lists, but I am sure you meant not
> to use single-ticks around the for-in argument, did ye.. ;-)
The && and || shortcuts are not nice to the environment,
Dalibor Topic writes:
> Hi,
>
> I was wondering if automake's CVS on savannah is still functioning properly
> since the last entries seem to be a couple of moths ago, and I have a hard time
> believing that, given that 1.7.5 has just been out for a few weeks. Any idea
> what's happening, or how to
> What do people thinks about Automake's removal of core dumps?
>
> I tend to think it's a misfeature.
I would tend to agree, if only for the reason that there are different
conventions on how core files are named, and a core file on one system
might be a completely legitimate (data) file on
> Dan> Second, why didn't it fix the permissions?
>
> No idea, Automake 1.5 is old.
> Does it still fail with Automake 1.7.2?
Yes, it is old, but one is stuck with it if one decides not to use
autoconf 2.5x just yet. I think the odd 1.5.x bugfix release would
be in order.
Eric Siegerman writes:
> On Tue, Dec 03, 2002 at 05:00:36PM +0100, Lukas Österreicher wrote:
> > How to install automake 1.4 and 1.5 at the same time on a redhat 7.2 system
> > (quite a few up2date packages installed already) in the described manner so I
> > dont have to worry about version incompa
Earnie Boyd writes:
> [EMAIL PROTECTED] wrote:
> >
> >Otherwise, I'm also subscribed on the list, so no need to CC me in every
> >post :-)
>
> It is a function of the mail client "Reply-All" event to add you in the
> distribution of the response. If you don't wish personal copies as well
> as l
[EMAIL PROTECTED] writes:
>
> Wow, that saves me dual implementation of 'debug' and 'release' make
> targets. cool :-)
>
> Yet 2 more newbie questions:
>
> Q1. Why do I get:
> -I. -I. -I.
> when make runs gcc?
> peekeing in the Makefile.in reveals:
>
> DEFAULT_INCLUDES = -I. -I$(srcdir) -I.
>
Since upgrading from autoconf 2.54 to 2.54b, automake 1.7.1 gives me tons
of warnings:
configure.ac:27: warning: back quotes and double quotes must not be escaped in:
$as_me:$LINENO: WARNING: \`$CC' requires \`$lt_cv_prog_cc_shlib' to build shared
libraries
configure.ac:27: warning: back quot
> Hi Lorrie,
>
> You are not talking to the right list.
>
> If you still think its a portability issue in ./configure,
> please trace this script with `sh -x ./configure --your-flags...'
> and send the output to [EMAIL PROTECTED]
I don't believe there is such an issue. I have used all recebt
( here it complaines about
argument to -L undefined/missing and the same for X_LIBS )
/ Thanks , Lars Segerlund.
Lars Hecking wrote:
>
> Well, what exactly are you doing? Which macros are in your configure.in?
> Are you using AC_PATH_X/AC_PATH_XTRA? In which way is the result
Lars Segerlund writes:
>
> Hi,
>
> I'm trying to test for X11 libraries and I am having some trouble
> with getting my Makefile.am ( automake ) to link right, basicly it wont
> set the path to the X libraries right.
>
> Does anybody have any pointers ? or tips ?
Well, what exactly are yo
Having a bit of a problem on OpenBSD.
I have a package that uses libpng, libfreetype (2.x), and jpeg library.
freetype 2.x is part of XFree86 and lives under /usr/X11R6, but some
packages in ports require libfreetype 1.x, which is also installed
(/usr/local).
Now, depending on the order of
Lawrence Teo writes:
> I was learning Automake last night, and I think I found a security
> vulnerability. I'm not sure if this is already known, but I couldn't
> find it on Bugtraq. The security vulnerability is the insecure
> creation of temporary files in the config.guess script which leads
> t
Joerg Anders writes:
> Unfortunately I'm not a autoconf/automake guru.
> But I think I can state: automake > 1.4 does not work.
>
> I can't say exactly what's wrong. But please try to
> use automake 1.6 togehther with the KDE3 default
> admin files. And you'll see: It is impossible.
Nobody here
> New in 1.6:
> * Autoconf 2.52 is required.
That's bad. I have no intention yet to switch my projects to 2.5x.
Tom Tromey writes:
> > "Itay" == Itay Meiri <[EMAIL PROTECTED]> writes:
>
> Itay> My project is built from several source subdirs. By default
> Itay> automake is using ar to build a single 'somelib.a' in every
> Itay> subdir before the final link. How can I make it use ld instead
> Itay> of a
> Can I develop a BSD library (or even LGPL) using automake, autoconf
> and libtool? Or using one of these three programs makes my library
> to fall under the GPL ?
Nope, not at all. See the "Distributing `configure' scripts" section
in the autoconf manual. Also, all files generated by these t
http://mail.gnu.org/pipermail/automake/2001-September/date.html
What a sad sight: fully one third of all list messages for this month
are spam. Other lists at gnu.org (and elsewhere) have been hit just
the same.
Is anyone at gnu.org going to do something about this?
If the list software
> Wich directory variable should I set to tell AC_CHECK_HEADER to search in ??
>
> For instance I have installed a package in /usr/local/mylib/include and
> /usr/local/mylib/lib and I would like configure to detect if mylib is not
> installed.
> I prefer not to put it in an environnemen
> : Same problem on AmigaOS (case-preserving, case-insensitive fs).
>
> Is this true for the new AmigaOS (the SDK/VM) too, or just the good old
> Amiga-hardware-specific one?
No idea at all, I don't follow. It is true for up to 3.1, and presumably
3.5.
(I'm in fact typing this from my Amiga
> The following problem exists: a new "Automake" directory
> has been added to the tree at the top level. However,
> on case-insensitive filesystems (such as DOS/Win32), this
> clashes with the 'automake' script.
> So it would be nice if the Automake dir could be relocated
> (say, perl/Automake
> : > I'd use "file.$(OBJEXT):", but that's just me.
> :
> : This fails with automake-1.4 (release), which is what I must use.
>
> I thought this would depend on Autoconf, not Automake.
I think you're right - if one uses AC_OBJEXT. We don't, and the generated
Makefiles don't define OBJEXT.
> : file.o: ../header.h
>
> I'd use "file.$(OBJEXT):", but that's just me.
This fails with automake-1.4 (release), which is what I must use.
> > In ./Makefile.am:
> >
> > ../header.h: $(srcdir)/../header.h.in
> > @( cd ..; $(MAKE) header.h )
>
> This doesn't help either.
... but adding
file.o: ../header.h
to the above does it.
Thanks Coffee-Lars ;-)
Lars J. Aas writes:
> On Fri, Mar 30, 2001 at 11:10:32AM +0100, Lars Hecking wrote:
> : How do I define a dependency on a header file in a different directory, eg.
> : the parent dir? I tried
> :
> : BUILT_SOURCES = ../header.h
>
> Try something like this:
&
Alexandre Oliva writes:
> On Mar 30, 2001, Lars Hecking <[EMAIL PROTECTED]> wrote:
>
> > Or is it just as simple as
>
> > file.o: ../header.h
>
> > in subdir/Makefile.am?
>
> This should work.
Hhm, it doesn't.
make: Fatal error: Don't k
How do I define a dependency on a header file in a different directory, eg.
the parent dir? I tried
BUILT_SOURCES = ../header.h
but automake tells me
automake: subdir/Makefile.am: not supported: source file `../header.h' is in
subdirectory
This is automake 1.4 (and it must work with aut
edward writes:
> hi akim,
>
> this is a plea to avoid using constructs like the "cp Makefile.am
> Makefile.AM" below. this kills us cygwin/windows people, and i for one, very
> much would like to keep automake, etc. working on window based platforms!
I fully support this. There are more platfo
> > I'm using BSD make here. That's the whole point of the exercise.
> > Requiring GNU make doesn't make much sense IMHO.
>
> OK, sorry. So actually you skip the GNU Make test, right? Is it
> possible to have some verbose output from BSD Make?
There are two related options: -d and -V. See
> I'm surprised Make doesn't speak here. Reading the test files, GNU
> Make is required, and GNU Make is usually verbose. In my case I have:
I'm using BSD make here. That's the whole point of the exercise.
Requiring GNU make doesn't make much sense IMHO.
> Could you
>
> srcdir=. VE
[Sorry, should've posted this to the list sooner. The system is OpenBSD 2.8
m68k (amiga). If necessary, I can try the same on i386.
This was automake-1.4c, but 1.4e has the same problems.]
Tom Tromey writes:
> Could you run this and send me the output?
>
> make TESTS='pr19.test target-
> I personally observe no failure. Please, post the result of
>
> make check TESTS='ansi3.test install2.test pr87.test subobj3.test
>target-cfalgs.test' VERBOSE=yes
target-cflags (note spelling) fails for me on OpenBSD as well. I have already
sent verbose output to Tom.
Tom Tromey writes:
> Could somebody with access to the BSD make please try the current cvs
> automake and report back?
>
> I've tried to implement support for `.include'. I think it works, but
> of course I'm not copmletely sure.
What exactly do you want us to try apart from make check?
I t
> > I'm looking for a way to run a specific target before check-TESTS.
>
> check: your-target
> your-target:
> do whatever you want
>
> If you really mean check-TESTS, use that instead of check.
D'oh. Why did this not work before I posted, but it works now??
Thanks!
I'm looking for a way to run a specific target before check-TESTS.
Both the local and the hook method (the latter doesn't support check,
btw) run the specified target after check-TESTS.
I know I can override check-TESTS, but I'd prefer not to.
Tom Tromey writes:
> > "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
>
> Akim> Once the `make check' finished, I'll check this in:
>
> Did the bug affect any of the existing test cases?
> If not I generally add a new test.
As long as the bug was there, I couldn't even get as far as r
[...]
> Now I have it. Sorry Lars... The test suite did not see anything...
> I'm fixing this.
I have added
. 's/\@VTEXI\@/' . $vtexi . '/g;'
+. 's/\@CONFIGURE_AC\@/' . $configure_ac . '/g;'
. 's,\@MDDIR\@,' . $conf_pat . ',g;',
Akim Demaille writes:
> ~/src/am % perl --versionnostromo 17:58
>
> This is perl, v5.6.0 built for i386-linux
[...]
> What do you have?
Tried both 5.005_03 and 5.6.0 built for sun4-solaris. It makes no difference.
Akim Demaille writes:
> >>>>> "Lars" == Lars Hecking <[EMAIL PROTECTED]> writes:
>
> Lars> I have that, but it still doesn't work.
>
> What did you type? How did it fail? Do your Makefile.in still have
> the @CONFIGURE_AC@ stuff?
> According to the headers of your mails, somehow, automake finally got
> created (the last failure you presented was at X-From-Line:
> [EMAIL PROTECTED] Thu Jan 18 13:06:26 2001). So, if indeed you have:
In all cases I posted, automake _did_ get created.
> ~/src/am % grep CONFIGURE_AC autom
> Could you please run
>
> diff automake.in automake
>
> and see if it helps you understanding what I'm trying to say? I agree
> I'm not clear, and I believe the diff will be much clearer than I am.
$ diff -u automake.in automake
--- automake.in Wed Jan 17 06:30:29 2001
+++ automake
> | At no time an old copy of automake is run.
>
> You don't seem to understand. Make a
>
> diff automake.in automake
>
> and I think you'll see what I mean.
% grep @CONFIGURE_AC@ Makefile.in
$(srcdir)/stamp-vti: automake.texi $(top_srcdir)/@CONFIGURE_AC@
%
If autoconf, not automake is r
> Yes, indeed. But I just switched me brains on, and understood.
>
> Sure you have the new .am files, but since the Makefile want to update
> the Makefiles first, you run an old automake which does not, indeed,
> substitute @CONFIGURE_AC@. So find a means, but you have to `make
> automake' bef
> But your output, compared to mine, contains:
>
> $ make dist
> cd . && /tmp/automake/aclocal --acdir=m4
> cd . && /tmp/automake/automake --amdir=. --gnits Makefile
> cd . && /bin/sh /tmp/automake/missing --run autoconf
>
> i.e., your files are not up to date. Try from a freshly checked out
>
> Did you install completely automake? I don't see that problem showing
> up. Could you deonstrate the failure in a few steps? Did the test suite
> run OK?
I posted everything I did. I did not install automake, only ran configure
and make dist straight from a copy of my checked-out tree.
Akim Demaille writes:
> Will be applied within a couple of minutes.
I don't think this is working as intended.
cvs automake as of now. autoconf 2.13.
$ ./configure
creating cache ./config.cache
checking for a BSD compatible install... /usr/local/gnu/bin/install -c
checking whether build envir
Alexander Olefirenko writes:
>
> Hello !
> Can anybody tell me what to do if building a library i need to link it with
> static lib (lib*.a)? While linking libtool tells there's a problims with linking
> with files with my lib, but linking it by hand works fine ...
> Is there anysolvation for thi
> > > see the -R option of ld.
> >
> > Or the LD_RUN_PATH env variable.
>
> -R overrides that, so it's (presumably) less subject to error.
LD_RUN_PATH is a nice workaround for stupid software that ignores
LDFLAGS (like php, although IIRC the issue there was that libtool
1.3 does not pass L
> > Here's the thing: This works fine on Linux. I only get the error on Solaris 7.
> > I have all the latest GNU tools installed, and I'm installing the library in
> > usr/local. I am not setting LD_LIBRARY_PATH, and I use the -L/usr/local/lib
> > argument when linking the library to the program.
> Is make -q portable? If so I could speed up my parallel built source
> patch somewhat.
All systems I have access to, plus the *BSDs support it.
System 7 doesn't, but maybe someone can find an example
closer to reality, maybe Ultrix ;-)
Alexandre Oliva writes:
> On Jun 22, 2000, Lars Hecking <[EMAIL PROTECTED]> wrote:
>
> > This is highly confusing, and should be rephrased
>
> It doesn't make much sense to rephrase it now that we have a
> completely different dependency tracking mechanism :
The automake 1.4 manual, and also the cvs version, says under
OMIT_DEPENDENCIES:
| When added to the @file{Makefile.in}, the dependencies have all
| system-specific dependencies automatically removed. This can be done by
| listing the files in @samp{OMIT_DEPENDENCIES}. For instance all
| ref
> Pavel> I still insist that no directories should be removed by "make
> Pavel> uninstall" unless they defininely belong to the package being
> Pavel> uninstalled.
>
> I doubt there is any way to determine this.
>
> Pavel> I don't want to figure out why /usr/local/man/man8 is not
> Pavel> write
> : Is there any value to keeping /usr/local/share, if it's empty?
> : Theorectically yes, but the next package that needs it will recreate it
> : anyway. Implementation would be simplified with this assumption.
>
> I say, remove /usr/local and even /usr if possible ;)
Why stop there? ;-))
> If it's an automake'd package, or it follows the GNU coding
> guidelines, it'll mkinstalldirs the directories.
mkinstalldirs does not keep track of what it creates. It does not
care whether part of the path to be created exists already, it just
mkdir's the missing dirs.
> But it does crea
Assar Westerlund writes:
> Currently automake does not remove directories in `make uninstall' and
> I did not find any text regarding this in the GNU coding guidelines
> either. So what's the right thing to do here?
>
> a) always remove the directories
> b) just remove the directories that were
Lars J. Aas writes:
> BTW, is anyone cataloguing these kinds of bourne shell bugs/anomalies
> somewhere? Seems like something like that would be a *very* useful resource
> for portable shell script programmers...
>
> Lars J
There is a Unix shell FAQ out there, but the document I have here
i
Akim Demaille writes:
> Ralf Corsepius sent me this morning a detailed PR with about the same
> behavior. I'm highly tempted to consider this a bash bug, unless
> someone can demonstrate the usefulness of the following feature...
I tend to agree. I ran your little script with /bin/sh and /bin/k
67 matches
Mail list logo
