> "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.
Aki
> "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
> "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: c
> "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 Per
> "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
> "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes:
Alex> Here is a new version of the patsubst patch against cvs HEAD.
Sorry I haven't been following this thread until now. Only in the
last few weeks have I really started reading automake email again. If
your message is buried too deep i
> "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes:
Alex> + (read_main_am_file): call expand_contents to output
Alex> + variables.
I'm concerned about this (referenced) part of the patch.
Suppose we have a Makefile.am like this:
if FOO
var = a b c
else
var = d e f
endif
> "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
>>>>> "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 th
> "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
>> 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 tar
> "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 it
> "Akim" == akim <[EMAIL PROTECTED]> writes:
Akim> I wonder why we have a hard coded list list this in subdirs.am:
Akim> [ ... -recursive targets ... ]
Historical reasons only, ie, I never thought of it.
Akim> Not only to I find this more pleasant, but most importantly it's
Akim> a win for
> "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
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Here is the updated version of the patch.
This patch still has a problem. See below.
Akim> Note that there is a new side effect to my patch: the
Akim> (un)?install-man targets appeared (since you said they were
Akim> required) in
> "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> * automake.in (&handle_merge_targets, &do_one_merge_target): Don't
Akim> work on targets handled by %dependencies.
Akim> (&handle_factored_dependencies): Do it.
Akim> * install.am: Install install-exec, install-data and unins
> "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 (&handle_man_pages): $found is dead.
Ok.
Which patch renders it dead?
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-
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> +&am_line_error ('SUBDIRS',
Akim> + "AM_GNU_GETTEXT used but \`po' not in SUBDIRS")
Akim> + if $contents{'SUBDIRS'} !~ /\bpo\b/;
Akim> +&am_line_error ('SUBDIRS',
Akim> + "AM_GNU_GETTEXT used but
> "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): Likewi
> "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 +=
> "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
> "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
Akim> Not only to I find this more pleasant, but most importantly it's
Akim> a win for Automake (we can have more modular *.am files which
Akim> register their own recursive targets), and it's a win for users
Akim> who can += on RECURSIVE_TARGETS.
>> In the not-too-distant past, you couldn't `+='
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> . &transform_cond ('BASE' => $strip_subdir,
Akim>'EXEC' => $X =~ /exec/)
This is still wrong.
User-defined directory names follow the `exec'-name test.
autoconf/au
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> I think I have this right too, since not all the *.am file
Akim> depend on ?EXEC?. See SCRIPTS and PROGRAMS below.
The point is that it is the directory name and not the primary that
determines which install-* target to use.
For i
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Tom> Instead they have to use &variable_value or &variable_value_as_list.
Akim> &am_line_error ('SUBDIRS',
Akim> "AM_GNU_GETTEXT used but \`po' not in SUBDIRS")
Akim> if &variable_value ('SUBDIRS') !~ /\bpo\b/;
I
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> .am:19: invalid variable `mysysconfdir_DATA'
This should read `Makefile.am:19:...'.
Do you know why it broke?
Tom
> "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 c
> "Akim" == akim <[EMAIL PROTECTED]> writes:
Akim> I will look at this tomorrow and fix it. Without looking at the
Akim> code, I think I must have been somewhat too systematic Iin
Akim> inserting ?EXEC?, I don't think info page should depend on exec
Akim> vs. data. Tom? I'm not sure of my
>> 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 ins
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Add support for `-f', `-V', `-A', `-h'.
Akim> + -h, --help print this help, then exit
Akim> + -V, --version print version number, then exit
I don't see any point in having short forms here.
Akim> - --
> "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',
A
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.texi (Invoking Automake): Remove dead options.
Ok. Thanks!
Tom
> "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> +(my $me = $0) =~ s,.*[\\/],,;
However, given that you strip the directory this is ok.
What I hate are
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in: Use File::Basename.
Akim> (&dirname, &basename): Remove.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&handle_dist): Use &transform instead of dedicated
Akim> magic for DISTDIRS.
Akim> But be sure to always do it.
Akim> * distdir.am: Adjust.
This is ok, but...
Akim> - grep ($dist_dirs{'$(distdir)/' . $_} = 1,
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&transform_cond): Merge into...
Akim> (&transform): this.
Akim> Adjust all uses.
Ok.
Tom
> "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
> "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 discover
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
adl> I don't care about depend.m4, this adds only the missing changes
adl> from m4/missing.m4. Note that this also fix a bug in
adl> AC_MISSING_INSTALL_SH which was using ${ac_auxdir} instead of
adl> ${ac_aux_dir}.
Why is this nee
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
adl> 2001-02-25 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
adl>* header-vars.am (INSTALL_STRIP_FLAG): Remove (obsolete).
I checked this in.
Tom
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
Tom> I think relying on a subdir `make' invocation expanding
Tom> `INSTALL_PROGRAM' correctly is not too likely to work.
adl> I still don't and would really like to get more feedback on this.
adl> The only workaround I can think o
> "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, th
> "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, ba
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&am_install_var): Recognize whether predefined
Akim> directories are `data' or `exec'.
Akim> * libs.am, ltlib.am, progs.am, python.am, scripts.am: Install
Akim> ?EXEC?.
You checked this in already, which is fi
> "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,
> "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
comp
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * texinfos.am: No ?EXEC? hook as currently installing TEXINFOS is
Akim> necessarily in infodir.
Ok.
Akim> -?EXEC??INSTALL-INFO?insexec-data-am: install-info-am
Akim> -?!EXEC??INSTALL-INFO?install-data-am: install-in
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.
A
> "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 a
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
adl> This can be easily fixed by changing the distdir code to look for
adl> files in the builddir first and failling back to look in the
adl> srcdir if needed. But maybe this is not the right fix; maybe
adl> bison should not output
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, d
> "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
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> It fails on RedHat 6.2, but not 7.0. I believe it's a Perl
Pavel> issue. Not sure if I'll have time today to look at this.
I'm running 6.2 and it works for me.
Tom
> "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 sh
> "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 thi
Tom> I think what we want is for the positioning of the .c file not to
Tom> matter for the developer, but for the file to end up in the
Tom> distribution made by `make dist'.
adl> The following is how I intended to fix this. I'm not sure
adl> it's what you want. Anyway the patch below won't app
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Let's make it run ten times faster...
Cool!
Akim> * automake.in (&transform): Be sure to remove the `\n' with ?FOO?
Akim> transformations.
Akim> (&file_contents): Let `$command' remove the Automake commands, and
Akim> nor
> "Arjan" == Arjan J Molenaar <[EMAIL PROTECTED]> writes:
Arjan> Imagine this: I want to build the gnome-libs from
Arjan> source. Therefore I need GLib, GTK+, Pango and a few other
Arjan> packages already build and installed. It would be nice
Arjan> (especially for developers) to make sure GL
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Question: why do we grep . after grep -v? It is not guaranteed that
Akim> grep -v will exit positive when it output something?
I don't know. cvs annotate claims you added those lines. In the past
we used `wc -l'. If it works wit
Akim> * automake.in (&handle_single_transform_list, &add_depend2): Let
Akim> $lang_specific_files{$lang} be a list instead of a string.
Ok.
Tom
Akim> * automake.in: Preparation for `use strict': Move the
Akim> initialization of the constants to the top, from...
Akim> (&initialize_global_constants): here.
Ok.
Tom
Akim> * automake.in ($am_file): Use vars.
Akim> ($am_file_name, $in_file_name): Private to &generate_makefile.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> I've left the comments related to these vars at both their
Akim> declarations, and their initialization because I don't know
Akim> where you, Tom, would like to keep them. Personally, I'd keep
Akim> it at there declaration, but...
Akim> * automake.in (%am_vars, @var_list, %def_type): Globals.
Akim> (&initialize_per_input): Initialize them.
Akim> (&read_main_am_file): Don't local them.
Akim> (&get_object_extension): $objext is private.
Akim> (&handle_single_transform_list): $lang is.
Akim> (&handle_ltlibraries):
Akim> * automake.in ($am_relative_dir): Global.
Akim> (&initialize_per_input): Init it.
Akim> (%make_list, @make_input_list): My them from
Akim> (&scan_autoconf_files): here.
Akim> (&require_file_internal): Mying changes.
This is ok, but please check this in with the bug fix (90-errdir)
Akim> use strict is almost happy, there remains one var causing
Akim> problems: require_file_found, which I did not fix (it'd be easy)
Akim> because there is a dirty hack for depcomp. Tom, why does it
Akim> have that special handling? It does not follow the regular
Akim> rules?
I don't know any
> "Dean" == Dean Hoover <[EMAIL PROTECTED]> writes:
>> make clean all CFLAGS=-ggdb
Dean> The sources are c++, so should I set CXXFLAGS instead?
Yes.
Dean> Is this somewhere in the documents?
It ought to be.
If not please tell us.
Tom
ven't gotten around to
Rusty> filling out the paperwork).
It did:
2000-12-23 Tom Tromey <[EMAIL PROTECTED]>
From Rusty Ballinger:
* automake.in (handle_java): Don't skip `noinst' prefix.
Rusty> hippo_jar_SOURCES = \
Rusty> com/fo
Akim> * automake.in (&require_file_internal): $errfile must be
Akim> independent from the loop on the directories.
Ok.
Tom
Akim> * automake.in (&generate_makefile): Call &initialize_per_input
Akim> *before* setting $am_file_name and $in_file_name.
Ok.
Tom
Akim> * automake.in (&pretty_print_internal): Don't output useless
Akim> spaces.
Akim> (define_pretty_variable): Don't issue the space after the `=' sign
Akim> to avoid trailing spaces in Makefile.ins.
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: Require AC_PROG_INSTALL in...
Akim> (&scan_autoconf_files): here.
Ok.
Tom
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 (&am_install_var): Remove $cygxform, unused.
Ok.
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, an
Akim> * automake.in (&do_one_merge_target): Remove, was only called from...
Akim> (&handle_merge_targets): here for `all'.
Akim> Adjust.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> It was bizarre to support install-info, but not uninstall-info.
Akim> In addition, install-info, being non regular, was taking risks,
Akim> such as not working properly in the case of recursives
Akim> directories (not that it actuall
> "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 be
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Is there any reason not to merge those two guys? The idea seems
Akim> to be that check_PROGRAMS etc. shall be run first. Any reason
Akim> to have this?
We guarantee that all check_PROGRAMS (or whatever) will be built
before the te
Akim> * subdir4.test (depcomp): Don't create it, defs does.
Ok.
Tom
Akim> * automake.in (&file_contents): Map MAINTAINER-MODE to
Akim> @MAINTAINER_MODE_TRUE@ or nothing.
Akim> * configure.am, remake-hdr.am, remake.am, texi-vers.am: Adjust.
Akim> Suggested by Tom.
Ok.
Thanks!
Tom
Akim> There is one big twofold change introduced by this change.
Akim> First all-redirect no longer exists. In fact I don't even
Akim> understand why it existed
I don't remember. It might have been to avoid putting config.h
machinery into &do_one_merge_target. Or it might have been an obscure
> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
Mo> After running "make distclean" on a big project I found myself
Mo> quite miffed at the fact that it reran the whole configure process
Mo> (which takes a long time) before executing the distclean rule.
It should only do that if the configure
501 - 600 of 1295 matches
Mail list logo
