Akim * automake.in (generate_makefile): Call initialize_per_input
Akim *before* setting $am_file_name and $in_file_name.
Ok.
Tom
Akim * configure.am: New file.
Akim * automake.in (file_contents): Transform CONFIGURE-AC.
Akim (handle_texinfo, handle_configure): Don't transform
Akim CONFIGURE_AM.
Akim (handle_configure): Use `configure.am'.
Akim * remake-hdr.am, remake.am, texi-vers.am: Adjust to
Akim
Akim * automake.in (file_contents): Transform LIBTOOL.
Akim (am_install_var): Remove $ltxform.
Akim * ltlib.am, progs.am: Adjust.
Ok.
I'm not convinced this really makes things cleaner.
It is just shifting the ugliness around.
Tom
Akim * automake.in (%required_targets, %dependencies): Add dvi, info,
Akim dvi-am, info-am.
Akim (@info, @dvi): Remove.
Akim (handle_texinfo, handle_merge_targets): Adjust.
Akim (handle_factored_dependencies): Required targets are phony.
Akim * texinfos.am: Build info, dvi, and the
Akim * automake.in (do_one_merge_target): Remove, was only called from...
Akim (handle_merge_targets): here for `all'.
Akim Adjust.
Ok.
Tom
"adl" == Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
adl I have tested install-strip for cross-compilation with CVS
adl Automake, doing both an in-place and a VPATH build (with relative
adl paths, I have not tested absolute paths). It works here, great
adl :)
Good.
adl-
Pavel I believe, the best fix will be to have tests/defs to copy the
Pavel right install-sh instead of creating an empty file.
I agree. I have a patch for this which I'll check in once the test
suite is done.
Tom
Pavel 1) "make dist" must ensure that out-of-date generated
Pavel distributable files (parser.c, Makefile.in etc) are not
Pavel included in the tarball either by running "make all" or
Pavel otherwise. Yes or no?
Yes. This has been on the to-do list for a long time.
I don't recall what has been
"Carsten" == Carsten Menn [EMAIL PROTECTED] writes:
$ cd $(srcdir)
$ mkdir bin-i686-linux; cd bin-i686-linux
$ ../configure --prefix=...
Carsten thank you for your quick response.
Carsten Unfortunately that's not exactly what I wanted.
Carsten The OS and the architecture should be
"adl" == Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
adl Is it an "ok" for my proposal or a "no, keep it as it is now"?
adl Right now, I would have to call AC_CHECK_TOOL([STRIP],[strip])
adl in my configure.in *before* calling AM_INIT_AUTOMAKE to make
adl thinks work.
Yeah. I think we
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in ($me): New.
Akim Use it.
Akim (usage): Display your full name.
I use simply `automake' on purpose.
Akim So I won't apply this part. I made that change because it's
Akim consistent which most tools:
Sorry, that was
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim So it is my (today's :) understanding that I did wrong to have
Akim some primaries independent from the dir name, right?
Right. The primaries are irrelevant at this stage.
Akim But both CVS and 1.4 refuse sbin_DATA :(
Sorry, bad
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
How smart is Perl?
I used to have this as a global so that it wasn't reevaluated each
time through the loop. It never changes -- it is a constant
structure.
Akim I privileged readability and modularity over efficiency.
Me, too, but:
*
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
* A user-defined directory is valid for any primary
Akim My understanding of texinfos.am is that this is not supported
Akim for _TEXINFOS. Yet? Should it?
True, it isn't. I don't think we need to support it. Nobody has ever
complained
Akim I tend to think it is the same for mans.am.
I think you're right.
Man pages have to be handled specially.
Nobody has ever complained about this not working right either.
Tom
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in (add_depend2): Transform AMDEP.
Akim (handle_clean): Transform MCFILES and MFILES.
Akim (file_contents): Transform MAINTAINER_MODE.
Akim (transform): Use `%', not `@'.
Akim Adjust all the *.am files.
Akim *
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * mans.am: s/INSTALL_MAN/INSTALL-MAN/.
Akim * automake.in (handle_clean): Don't escape what's given to
Akim transform.
Ok.
Tom
Akim - --amdir=DIR directory storing config files
Akim + -A, --amdir=DIR directory storing config files
I definitely don't want a short form for this.
This option shouldn't really be used by users.
Akim I use it all the time when hacking Autoconf and Automake :)
You aren't
Akim --
I think one of your patches probably broke `make dist-all'.
Right now it ends up depending on each dist target that is used.
However each such target ends by removing the dist directory.
The point of having dist-all is that it is more efficient to simply
create the dist directory once,
"Pavel" == Pavel Roskin [EMAIL PROTECTED] writes:
Pavel I don't quite understand whether your test is supposed to work
Pavel or not. It's failing for me (besides the typo in
Pavel tests/Makefile.am that I've just fixed).
Alexandre claims it fails.
I've updated it a bit. Now it works for me.
"Akim" == akim [EMAIL PROTECTED] writes:
Akim My bad, I forgot to remove `dir' from the _DATA var.
Oops, I missed that too.
Akim mybindir = $(bindir)/my
Akim mybin_DATA = doto
User defined variables are handled by name.
I agree that this case is handled correctly with the current cvs.
I think we should have a clean separation between internal and
external variables here. So how about renaming this as
`_am_installdirs' or something like that? I have a slight preference
for lower case internal macro names.
Akim What is the status the patch with _am_installdirs instead?
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in (scan_texinfo_file): Also compute the list of files
Akim to clean.
Akim Handle local errors.
Akim (handle_texinfo): Use it.
This is ok.
Akim +my @clean_suffixes = ('aux', 'dvi', 'log', 'ps', 'toc',
Akim +
"adl" == Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
Akim Your explanation is very correct. AC_CHECK_TOOL only needs
Akim host_alias, hence there was no reason to require AC_CANONICAL_*.
adl Has anyone a plan to change this in Automake?
Eventually when we move to traces this will change.
"adl" == Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
adl 2001-02-25 Alexandre Duret-Lutz [EMAIL PROTECTED]
adl* ChangeLog (2001-01-28): Remove entries for chunks not applied.
I'll check this in.
You don't actually need a ChangeLog entry for ChangeLog updates.
BTW I discovered a
"Derek" == Derek R Price [EMAIL PROTECTED] writes:
Derek require 5.004;
Derek use IO::File;
Derek my $fh = new IO::File " filetoread";
Derek while ($fh-getline)
Derek {
Derek dostuff $_;
Derek }
Switching automake to use this would be good.
Tom
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim (handle_texinfo, handle_man_pages, am_install_var): Let your
Akim files define INSTALLDIRS.
Oh, yeah -- if we let the user set INSTALLDIRS then that should be
documented.
Tom
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim handle install and install-am.
Akim * install.am: Do it.
Ok.
Tom
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in: `my' the globals.
Ok.
Tom
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in (variable_defined, variable_value_as_list_worker):
Akim If $VAR is effectively a variable, don't die if it's also a
Akim target.
Akim Plus some formatting changes.
Ok.
Tom
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim Internally just store the conditionals as space separated lists of
Akim CONDITIONS (instead of @CONDITIONS@).
Ok.
Tom
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in (handle_merge_targets): Move `install-strip' from
Akim here...
Akim * install.am: to here.
This is almost fine, except
* The patch it depends on needs work
* This appears to use an old version of the install-strip
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in (initialize_per_input): %targets_conditionals is
Akim new.
Akim (read_am_file): When slurping a rule, set the target related
Akim variable, and no variable related variable.
Akim (file_contents): Likewise.
Akim *
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Parts of this patch I like, but parts I don't like so much.
Akim (file_contents): Be able to grow Automake macros with `+='.
This is a nice idea, but it is problematic. Suppose the user defines
a variable that a .am file tries to +=. This
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim So I replaced each occurrence of $recursive_install (which name
Akim was quite confusing anyway IMHO) with it's definition.
This is probably just some historical relic.
Akim * automake.in ($install_recursive): Remove, replaced with
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in (handle_merge_targets, do_one_merge_target): Don't
Akim handle installcheck and installcheck-am.
Akim * install.am: Do it.
Ok.
Tom
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in (handle_texinfo): Remove code handled by texinfos.am.
Ok.
Tom
"Tom" == Tom Tromey [EMAIL PROTECTED] writes:
Following up my own post...
Tom if FOO
Tom var = a b c
Tom else
Tom var = d e f
Tom endif
Tom derived = $(var:%=%.c)
Tom Will this work correctly? In this situation we have to give
Tom `derived' the same conditio
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
If it is a dependency then it won't work properly with a parallel
make. That's because the -hook for must be run after all the other
rules.
Akim Why don't we use dependencies to say that -hook must be run
Akim last, instead of using the
I think this has a bug.
It is ok if you fix it though.
Akim oops, I missed that part. What do you mean?
I just meant the =~ reversal I pointed out. I only cited the
ChangeLog entry so we'd be clear on which patch. Sorry for the
confusion.
Tom
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim -local ($in_ac_output, $in_ac_replace) = (0, 0);
Akim +# Watchout: these guys need dynamic scope!
Why remove the other local() though?
Those variables also have dynamic scope :-(
Akim Hm, do they?
Ok, thanks.
Tom
"Tom" == Tom Tromey [EMAIL PROTECTED] writes:
Tom 2. Pushing the hook out means that if the user has a -local as
Tom well as a -hook then we have to rewrite the -local target to add
Tom a new dependency. We've never rewritten user targets, so this is
Tom a major(-ish) change to c
"Derek" == Derek R Price [EMAIL PROTECTED] writes:
if FOO
var = a b
endif
derived = $(var:%=%.c)
if BAR
var = c d
endif
Derek Isn't the order irrelevant here since derived won't be
Derek evaluated until it's used?
No, because we're talking about having automake itself expand the
"Pavel" == Pavel Roskin [EMAIL PROTECTED] writes:
Pavel You recently applied a patch to tests/target-cflags.test
Pavel without mentioning it in ChangeLog. Maybe you didn't mean to
Pavel commit that change?
Oops.
Pavel * tests/target-cflags.test: Don't use subshell to configure in
Pavel
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim What would you say: make it local (i.e., install-man1 builds
Akim MANS1), or global as it was. If easy, I prefer the first
Akim solution, otherwise backup to the previous state.
The first solution is ok.
But note that install-man1 must
"Paul" == Paul Martinolich [EMAIL PROTECTED] writes:
Paul lib_LIBRARIES = libjunk.a
Paul libjunk_a_SOURCES = src/a/a.c src/b/b.c
Paul But if one of the source is a FORTRAN source, it will not work
Paul :-( Is this a simple or difficult fix?
I'm a bit suprised by this.
How does it not work?
"Derek" == Derek R Price [EMAIL PROTECTED] writes:
Derek Whoops. Excuse me. That works in every case except ($test).
Derek The subshell created by parens breaks things. I guess that
Derek isn't all that robust.
I'm not too concerned about this.
Once we switch fully to using traces, autoconf
"Derek" == Derek R Price [EMAIL PROTECTED] writes:
I imagine we'll have to radically revamp the test suite when we
move to using autoconf's tracing feature. The current test suite
is very dumb and doesn't usually generate a correct configure.in.
Derek I'm working on this so I can test my
"Derek" == Derek R Price [EMAIL PROTECTED] writes:
Derek Is there a good reason that the following constructs
Derek occasionally appear in 'configure.in's as created by the test
Derek suite?
This is almost certainly just a remnant of old times, before
AM_INIT_AUTOMAKE existed.
Tom
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim -install-man@SECTION@:
Akim +install-man@SECTION@: $(man@SECTION@_MANS) $(man_MANS)
Don't forget to update ChangeLog.
This is ok.
Tom
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim Six, six for them! (I'm not counting those for file handles,
Akim which perl refuses as my, not sure to understand why).
The way file handles work is another reason to dislike Perl. At
least, I've always found them confusing.
Akim *
"Matt" == Matthew R MacIntyre [EMAIL PROTECTED] writes:
Matt Is there an easy way to add a new recursive target to a
Matt top-level Makefile.am?
Nope.
Matt For instance, I have a number of different directories with an
Matt "html" target in them. I'd like to have an easy way to run
Matt
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim In fact, I've had to finish the job, because the following test
Akim was falling:
Akim cat Makefile.am 'END'
Akim bin_PROGRAMS = consud
Akim ## Note next line is target, not variable.
Akim consud_SOURCES: consud.c
Akim
"Kevin" == Kevin Ryde [EMAIL PROTECTED] writes:
Kevin It'd be nice to be able to embed little fragments of perl to do
Kevin things like that, for the "static" case that is. But perhaps
Kevin that idea has come up before.
I've long resisted letting the user extend Makefile.am with Perl code.
I
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim Yep, by default Automake must not let the users do nonportable
Akim things. I'm sorry about that, but I believe it's a strong
Akim requirement.
I'm finally following up to this -- it was buried in my overly large
automake mailbox.
Akim --
One problem with target/variable separation is that am_line_error
accepts a variable name as its first argument. If they are separate
then some calls to this may become ambiguous. This can probably be
fixed, but it is something to be aware of.
Tom
"Pavel" == Pavel Roskin [EMAIL PROTECTED] writes:
-($from = $2) =~ s/(\W)/\\$1/g;
+($from = $2) =~ s/(\W)/$1/g;
Pavel I don't understrand this. This change will affect the
Pavel traditional rules as well. It should probably be a separate
Pavel patch if it fixes a
"Patrick" == Patrick Guio [EMAIL PROTECTED] writes:
Sorry for the long delay in my reply to this...
Patrick I am not sure if this is to be adressed to libtool or maybe
Patrick automake since the problem might come from depcom...
Could be either.
Patrick Anyway I am trying to build a c++
"Pavel" == Pavel Roskin [EMAIL PROTECTED] writes:
Pavel ChangeLog:
Pavel * header-vars.am: Remove tabs before variable definitions.
Thanks.
Tom
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim I don't understand this:
Akim $(mkinstalldirs) $(distdir)/foo foo
Akim What is this second foo doing here?
Bug.
Tom
"Paul" == Paul Martinolich [EMAIL PROTECTED] writes:
Paul1260 require_config_file ($FOREIGN, 'compile')
Paul1261 if $lang eq 'c';
Paul This makes the error about not finding './compile' go away.
Paul I now have it in config subdirectory. Or perhaps,
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim This patch applies the same transformation, factoring, to
Akim install-data, install-exec and uninstall.
Akim Below are first presented the Makefiles of Automake. There is
Akim obviously a problem, which I do not solve in this already too
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim This patch applies the same transformation, factoring, to
Akim install-data, install-exec and uninstall.
I haven't read this patch yet but I wanted to respond to some comments
before I did.
Akim Below are first presented the Makefiles of
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim $(mkinstalldirs) $(distdir)/foo foo
Akim What is this second foo doing here?
I checked in a test for this.
Tom
"Pavel" == Pavel Roskin [EMAIL PROTECTED] writes:
Pavel Also it would be nice if you checked on some projects that the
Pavel makefiles don't change. I see you are doing it with
Pavel Autoconf. Consider a bigger project for the test (Lesstif
Pavel should be fine).
Sometimes I test against a
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim -install-man: $(MANS)
Akim - @$(NORMAL_INSTALL)
Akim - $(MAKE) $(AM_MAKEFLAGS) install-man1
I'm concerned about this.
Before this change, `install-man' would ensure that the man pages were
rebuilt. After this change, it
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in: Formatting changes.
Please say something like "Use my instead of local", since this goes
beyond mere formatting.
Akim -local ($sect, %sections, %vlist);
Akim +local (%sections, %vlist);
I think the new standard
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in: Formatting and mying changes.
Ok.
Akim + # FIXME: This code is mad, rewrite!
At the time it was hard to find a better solution.
Maybe we can do better now. Or maybe not.
Or are you just referring to
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in (am_install_var): Don't hook on the clean targets
Akim and .PHONY.
Akim * data-clean.am, java-clean.am, libs-clean.am, lisp-clean.am,
Akim * ltlib-clean.am, progs-clean.am, python-clean.am, tags-clean.am:
Akim Do
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in: Formatting and mying changes.
Ok.
Could you add a `maintainer-check' rule to ensure that `local' doesn't
creep back into the source? That would be handy...
Tom
"Pavel" == Pavel Roskin [EMAIL PROTECTED] writes:
Pavel It should be [EMAIL PROTECTED] for consistency with
Pavel Autoconf.
... and every other project in existence.
This change is fine with me. Someone else has to create the list
though.
Can it be archived at GNU? If not, tell me when you
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim As a specific advice, please, never test again any of the
Akim Autotools as root, as they are not meant for it, and this
Akim produces false alarms.
Maybe we could modify `defs' to `exit 77' when the user is root.
I'm not too concerned
"Florent" == Florent Devin [EMAIL PROTECTED] writes:
Florent I have seen a var which is BUILT_SOURCES.
Florent Affecting this variable causes the make process build the var before
Florent anything. (If I am wrong please tell me).
Florent But is it necessary to build this var if the cmd is make
"Robert" == Robert Boehne [EMAIL PROTECTED] writes:
Robert The problem is that even though
Robert progname_SOURCES = 'm$in.cpp'
Robert is in Makefile.am, am_progname_OBJECTS is empty.
Robert Is this not supported by Automake, or is it a bug?
It is both. Supporting it is difficult, but given
"Lars" == Lars Hecking [EMAIL PROTECTED] writes:
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:
Lars I'm using BSD make here. That's the whole point of the exercise.
Lars Requiring GNU make doesn't
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim ifdef([m4_pattern_allow],
Akim [m4_pattern_allow([^AM_CFLAGS$])])dnl
Feel free to check in this change if you get to it before I do.
Tom
"Alexandre" == Alexandre Oliva [EMAIL PROTECTED] writes:
If Automake doesn't support $ in source file names, then I would
suggest that it isn't an important requirement for Libtool.
Alexandre I disagree. libtool can be used independently from
Alexandre automake. And, in fact, until libtool
"Jiva" == Jiva DeVoe [EMAIL PROTECTED] writes:
Jiva Well, I do this already, but what that does is remake my entire
Jiva project, when all I really want to do is cd into ONLY the part1/
Jiva directory and ONLY remake the portions that it depends on. In
Jiva other words, I want it to "cd
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in (dist_cmp): New.
Akim (handle_dist): Use it.
Akim Promote `my' over `local'.
Ok.
Beware: I believe there is one place in automake where local() is
required. I know that sucks. I think it is in the variable expansion
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * dist.am: Remove, merge into...
Akim * distdir.am: here. Use the neat sed snippet for banners.
Akim BTW, distcheck is phony.
Akim * automake.in (handle_dist_worker): Remove, merge into...
Akim (handle_dist): this.
Akim
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim It is on purpose my uses of uniq have no : it disables
Akim prototype checking.
Do we really want prototypes? I seem to remember Perl experts telling
me that they are confusing and weird.
Akim * distdir.am (GZIP_ENV): Define.
Akim *
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * distdir.am (distdir): Handle the DIST-TARGETS.
Akim * automake.in (handle_dist_worker): Don't.
This is ok if patch 34 goes in.
Tom
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim This patch includes all the diffs of Makefile.ins, i.e., subdirs'
Akim Makefile have not changed. The big change in the top Makefile.in
Akim comes from the fact that the so called `find complex command' is
Akim attached to distdir (where
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in (handle_tests_dejagnu): Move the definition of a
Akim default `site.exp' into...
Akim * dejagnu.am (site.exp): here.
Akim Use DOS compliant file names.
Ok.
Tom
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in (conditional_true_when): Modernize, simplify.
Akim Warning: `$comp' is now private (my), while it used to be
Akim `inherited' from a `local' elsewhere in the code. AFAICT it was
Akim wrong, but some dirty side effect
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * dist-vars.am: Remove, merge into...
Akim * distdir.am: this.
Akim * automake.in (dirname, basename, backname): Move at the top of
Akim the file so that prototypes are checked,
Akim Use them without `'.
Akim (handle_dist):
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in (check_ambiguous_conditional, read_main_am_file):
Akim Use a uniform naming scheme.
Akim (quote_cond_val, unquote_cond_val): Delete, dead code.
Akim (read_am_file): Fix conditioned definition of backslash continued
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim Ideally I'd say we need objects for variables, and have a
Akim uniformized handling of conditionalized/unconditinal variables.
This patch needed a lot less defense than you posted -- the only
reason conditionals were implemented in that
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Ideally we'd have some way to tell autoconf, "if this package can
be cross-compiled, then check for a cross `strip' as well". Maybe
there's an ugly way to do this.
Akim But I think your request is precisely AC_CHECK_TOOL. What
Akim exactly
"Tim" == Tim Van Holder [EMAIL PROTECTED] writes:
Nope, afraid not. Where did you get this mkinstalldirs?
Tim Hmm - then I don't really know where I got it. Some GNU package,
Tim I guess.
Without knowing where it came from I can't check it in. That's true
even if you have paperwork signed,
"Hari" == Raja R Harinath [EMAIL PROTECTED] writes:
Dependency files are different from .o files though. It would make
sense to write a temporary dependency file and then `mv' it on
success (or `rm' on failure).
Hari But, does 'gcc' have to do it? There are valid usage modes (use
Hari
"Pavel" == Pavel Roskin [EMAIL PROTECTED] writes:
Pavel AC_CHECK_TOOL([STRIP],[strip])
Yes, I wasn't thinking. I've removed this.
Ideally we'd have some way to tell autoconf, "if this package can be
cross-compiled, then check for a cross `strip' as well". Maybe
there's an ugly way to do
"Cliff" == Cliff Tsai [EMAIL PROTECTED] writes:
Cliff I write a simple program and using autoconf,automake,but
Cliff have following automake problem.
Cliff my Makefile.am is
Cliff bin_PROGRAMS = test
Cliff test_SOURCES = main.c help.c help.h
Cliff but encounter a
"Hari" == Raja R Harinath [EMAIL PROTECTED] writes:
Hari GCC 3.0 doesn't still exactly implement exactly what 'depcomp'
Hari wants.
Bummer.
Hari I don't know if this a GCC bug. I'm assuming it's not -- it
Hari makes sense to clean up if the compile fails; the compiler
Hari doesn't provide
"adl" == Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
adl 2001-01-17 Alexandre Duret-Lutz [EMAIL PROTECTED]
adl* automake.in (unquote_m4_arg): New function.
adl(scan_one_configure_file): Call unquote_m4_arg on
adlAM_CONFIG_HEADER argument, so that AM_CONFIG_HEADER([foobar.h])
"adl" == Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
adl 2001-01-18 Alexandre Duret-Lutz [EMAIL PROTECTED]
adl* automake.in (scan_one_configure_file): Unquote AC_CONFIG_AUX_DIR's
adlargument.
I checked this in.
Tom
"Paul" == Paul Martinolich [EMAIL PROTECTED] writes:
Paul AC_CONFIG_AUX_DIR([config])
Paul With automake-1.4d, in the first case the configure directory is
Paul `[config]' rather than `config'.
I just checked in a fix for this. It was waiting for copyright
paperwork which was approved today.
"Jeremy" == Jeremy Slade [EMAIL PROTECTED] writes:
Jeremy What I really want to build is 'swigShapeUtils.sl', which
Jeremy corresponds to the swigShapeUtils.pm module. But automake
Jeremy complains:
Jeremy automake: src/perl/swig/Makefile.am: `swigShapeUtils.la' is not a
Jeremy standard
"Richard" == Richard Boulton [EMAIL PROTECTED] writes:
Richard Makefile:1344: warning: overriding commands for target
Richard `libgst_la-gstparse.lo'
Richard Makefile:966: warning: ignoring old commands for target
Richard `libgst_la-gstparse.lo'
Thanks for the report.
Richard I've got a
"Pavel" == Pavel Roskin [EMAIL PROTECTED] writes:
Pavel In the Automake CVS the target "all" is not longer PHONY. Is it
Pavel a bug or an intentional change? If the later, what was the
Pavel reason?
Bug.
Pavel If the former, I'll try to find who's "guilty".
Probably me.
Tom
601 - 700 of 890 matches
Mail list logo
