> "Alex" == Alex Turner <[EMAIL PROTECTED]> writes:
Alex> What is the best way to have a script/program where $pkgdatadir
Alex> is located?
I assume you mean how to find pkgdatadir in a program?
Alex> For C, it's easy enough just to do
Alex> CCFLAGS=-DPKGDATADIR="\""$(pkgdatadir)"\"" but wh
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> elsif (/^\@(syncode|print)index \w+ (\w*)/)
Akim> {
Akim> push @clean_suffixes, "$1s";
Shouldn't that be "$2s" here?
Tom
> "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes:
>> Am I doing something wrong?
>> Notice that this problem only takes place with cygwin
Tim> Might be an EOL issue; sed is notorious for not recognizing a trailing \
Tim> in a DOS text file (it sees \ + CR + NL).
Tim> Try converting the f
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Then, I'd say we should have TAGS work all by itself, calling
Akim> TAGS-recursive. And tags is nothing but `tags: TAGS'. How does
Akim> it sound?
Sounds good to me.
Tom
Akim> * automake.in (&scan_aclocal_m4): Handle $relative_dir and special
Akim> variables.
Akim> Specify to the caller whether $regen_aclocal_m4.
Akim> (&handle_configure): Adjust.
Akim> Transform `REGEN-ACLOCAL-M4'.
Akim> * configure.am: Use it.
Akim> * tests/defs (me): New.
Akim>
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Also, I wondered for a long time whether we should introduce
Akim> lang specific files. Most of the content of register_language
Akim> calls, should probably be in a file, and some adhoc stuff in
Akim> lang_*_finish/rewrite could be
> "David" == David Simpson <[EMAIL PROTECTED]> writes:
David> Sorry to spam all list recipients, but I'm trying to contact
David> someone administering the automake mailing list. Basically, I
David> need to unsubscribe but automated attempts to automake-request
David> have failed (I don't ha
> "Jim" == Jim Meyering <[EMAIL PROTECTED]> writes:
> | Ok, I re-read your message. Why do we ever run `missing --run :'?
> | That seems weird.
Jim> I didn't know off hand either, but found this in
Jim> automake/m4/missing.m4:
Jim> if eval "$MISSING --run :"; then
What if we just change
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (Language): Add attributes `flags', `compile' and
Akim> `compiler'.
Akim> (&finish_languages, &handle_single_transform_list, &handle_dist)
Akim> (&add_depend2, ®ister_language): Use them and the `linker' and
Aki
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Tom> Objective C shouldn't be a `pure' language. My understanding is
Tom> that in this case you want to use the `C' linker. If not then
Tom> contact and ObjC hacker to get truer information.
Akim> So what should I actually do? I really
> "Lorenzo" == Lorenzo Bettini <[EMAIL PROTECTED]> writes:
Lorenzo> make dist is not a problem for me: I only wish I could have
Lorenzo> different "make install" rules, that's all :-)
If the programs are in different subdirs then there is nothing
preventing you from writing your own:
in
> "Adam" == Adam C Powell IV <[EMAIL PROTECTED]> writes:
Adam> Hmm, the "include" line seems to be copied verbatim into the
Adam> Makefile.in, so maybe when automake doesn't find the file, it
Adam> gives up and copies it?
Oh, I see -- any non-conforming `include' is passed through.
Your part
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
Lars> BUILT_SOURCES = header.h
Lars> # build $(BUILT_SOURCES) before entering subdirs
Lars> Makefile: $(BUILT_SOURCES)
Note this will only work with GNU make and is relatively bad besides.
Eg, try `make clean' and watch it rebuild the header
> "Jim" == Jim Meyering <[EMAIL PROTECTED]> writes:
Jim> It was only a problem when $@ was a shell built-in, like : or cd.
Ok, I re-read your message. Why do we ever run `missing --run :'?
That seems weird.
Tom
Tom> My reading is that this patch always generates an aclocal.m4
Tom> target, regardless of whether one is warranted.
Akim> Hm, no. I think you missed the first lines of the patch, or I
Akim> might have misunderstood what you mean:
I saw that code.
To me it looks like handle_aclocal_m4 is cal
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> -my $c_suffix = $yacc_suffix;
Akim> -$c_suffix =~ tr/y/c/;
Akim> -push (@suffixes, $yacc_suffix, $c_suffix);
Tom> Deleting this push seems wrong.
Tom> How else does this stuff end up on suffixes?
Akim> It is obtained vi
> "Lorenzo" == Lorenzo Bettini <[EMAIL PROTECTED]> writes:
Lorenzo> I mean that, e.g., java2html could be 1.7 and cpp2html 1.3,
Lorenzo> though they are in the same package, and possibly do
Lorenzo> something like make install_java2html...
Version numbers are up to you.
Automake wants to kn
Tom> Incidentally changes of this sort are ripe for test cases which
Tom> test expected behavior.
Akim> You're hitting the limits of my English :) I don't know if you say
Akim> ``follow what the existing tests say'' or ``this is typically
Akim> something new tests should check''.
I mean that if
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> In particular Automake cannot override user variables with
Akim> Automake variables.
Ok, that's good. But if the user defines a variable conditionally
then automake should still be able to define it when the condition
does not hold
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (Language): New package, temporarily in this file.
Akim> Use Class::Struct.
Akim> (Automake): New package.
Akim> (%languages): New.
Akim> (&handle_single_transform_list): Use the language object's `ansi'
Akim>
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> which means also, why do we look for the closure of PROGRAMS,
Akim> instead of just adding $(EXEEXT) to all its components and sub
Akim> components (i.e., inside sub vars such as $(SONE) above being a
Akim> sub var of targ_SOURCES)?
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&handle_single_transform_list): Remove $xbase,
Akim> unused.
Akim> (&handle_source_transform): All the variables have conditions now,
Akim> simplify.
Akim> (&variable_delete): Admit an argument @conds.
Akim>
> "Adam" == Adam C Powell IV <[EMAIL PROTECTED]> writes:
Adam> I think I'm going to go with option 1. The PETSc libs will be
Adam> linked just fine, but other system libs from MPI to BLAS are a
Adam> total crap-shoot without the ability to import the variable from
Adam> an included makefile.
> "Adam" == Adam C Powell IV <[EMAIL PROTECTED]> writes:
Adam>* hard-code the variable I had hoped to get from the foreign
Adam>makefile, which will break if it differs from platform to
Adam>platform or machine to machine.
Adam>* give up on cross-platform and hand-create .la
> "Adam" == Adam C Powell IV <[EMAIL PROTECTED]> writes:
Adam> configure.in and Makefile.am are attached, they're relatively
Adam> simple as these things go. If you run Debian (unstable), having
Adam> petsc-dev installed should make it all work. Note again that
Adam> PETSC_INCLUDE comes thr
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> This patch introduces one semantical difference: tags-recursive
Akim> is bound to tags, not TAGS as was before. I think (i) it is
Akim> cleaner, and (ii) anyway it seems to me that TAGS itself
Akim> performs its own recursion:
The
Akim> * automake.in ($source_suffix_pattern): Remove, unused.
Akim> %extension_map seems to have replaced it.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * ext-compile.am: New file.
Akim> * automake.in (&finish_languages): Output it.
Akim> Require a C linker if there are several registered source suffixes.
Akim> (&handle_compile): No longer push the `.c', `.o', `.obj', `.lo'
A
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&handle_compile): Extract from...
Akim> (&get_object_extension): here.
Akim> (&read_am_file): Call it.
Akim> ($included_generic_compile, $included_knr_compile)
Akim> ($included_libtool_compile): Remove.
Akim>
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Use AM_CONDITIONAL and if/endif for AMDEP.
Akim> * m4/depend.m4 (AM_DEP_TRACK): Use AM_CONDITIONAL to define AMDEP.
Akim> * automake.in (&add_depend2): Transform %AMDEP% into `AMDEP' (leading
Akim> to a configure time if/endi
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in: Use simple quotes to define the _PATTERN variables
Akim> to unobfuscate the regexps.
Akim> ($AM_CONDITIONAL_PATTERN): Let the user quote the variable.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * tags.am: Fix missing leading tabs.
Ok.
This would also fall under the "obvious bug fix" rule.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&rule_define): When you discover a suffix rules,
Akim> register the extensions for .SUFFIXES.
Akim> (&handle_texinfo): Don't register the suffixes.
Akim> (&get_object_extension): Don't register suffixes, let th
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * subdirs.am (RECURSIVE_TARGETS): New variable.
Akim> Use it.
Akim> * automake.in (&handle_subdirs): Output it.
Akim> (&file_contents_internal): Support value spread on several lines.
Ok.
I don't find this any cleaner than t
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Isn't this beautiful? A *.am file only change!
Akim> * subdirs.am: Don't define info related recursive targets.
Akim> * texinfos.am: Do.
... and here's why you made the change in 66-.
Thanks, this is ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&handle_man_pages): Rely on mans.am to define
Akim> man%SECTION%dir and MANS.
Akim> * mans.am: Do it.
Ok.
This patch made me realize that there is a bug in _MANS processing: we
don't handle dist_ or nodist_ pre
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> The aim of this patch and the next is to clarify the status of
Akim> variables: who owns them, and how their defined type (+=, := or
Akim> =) can change.
Akim> I end up with a rule which is somewhat unsatisfying:
Incidentally chang
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&variable_dump): Use %var_type properly.
Akim> (&variable_define): Enforce better overriding rules.
Akim> Handle the special case that used to handle...
Akim> (&define_pretty_variable): this.
Akim> Hence, don
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> The aim of this patch and the next is to clarify the status of
Akim> variables: who owns them, and how their defined type (+=, := or
Akim> =) can change.
Why does it matter who owns them?
Akim> I fail to understand why the user is
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> There is one test that fails with this patch, but I leave it on
Akim> purpose, because there is a choice to make: is it Makefile.in
Akim> that should be pretty, or is it Makefile?
Neither has to be pretty!
Akim> Hence my question:
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&handle_configure): Don't bother with optimizing
Akim> macro uses.
Ok.
I thought I ok'd this one already?
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&am_install_var): Transform DIST, and let the *.am
Akim> files handle DIST_COMMON.
Akim> * data.am, header.am, java.am, list.am, python.am, script.am: Set
Akim> DIST_COMMON.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (%dist_common): Remove.
Akim> (%configure_dist_common): Replace with...
Akim> ($configure_dist_common): this.
Akim> (&generate_makefile): Read the user file before using
Akim> push_dist_common, as it sets DIST
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
Derek> Is there some reason the automake test suite doesn't allow the
Derek> user to override its AUTOMAKE & ACLOCAL variables? I like to
Derek> do it on ocassion to compare the current behavior against my
Derek> installed version and th
> "Hair" == Raja R Harinath <[EMAIL PROTECTED]> writes:
Hair> from Raja R Harinath <[EMAIL PROTECTED]>
Hair> * depcomp (gcc3): Invert test condition.
Oops, thanks.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&get_object_extension): Use ansi2knr.am.
Akim> * clean-kr.am, kr-extra.am: Remove, merged into...
Akim> * ansi2knr.am: this new file.
ok
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * comp-vars.am: Remove, merged into...
Akim> * compile.am: here.
Akim> * automake.in (&get_object_extension): Adjust.
Ok.
Akim> +DEFS = @DEFS@%DEFAULT_INCLUDES%
At some point we want to fix this.
It is PR 132.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&transform): Fix an incredible bug which was
Akim> breaking the if/endif system.
Akim> ($ELSE_PATTERN): Admit an optional argument.
Ok.
Is there some kind of regression test for this?
That would be nice. Or ma
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&handle_aclocal_m4): Rename as...
Akim> (&scan_aclocal_m4): this.
Akim> Return the list of aclocal.m4 dependencies.
Akim> (&handle_configure): Invoke it, and use it when loading...
Akim> * configure.am: Templ
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * remake.am: Merge into...
Akim> * configure.am: ... here.
Akim> * automake.in (&handle_configure): Adjust.
Ok
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&condition_negate): New.
Akim> (&variable_conditions_permutations): Use it.
Akim> (&read_am_file, &file_contents): Use it on `else' clauses to
Akim> support `if FALSE'.
Akim> (&output_yacc_build_rule): Output
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&output_lex_build_rule): Output this...
Akim> * lex.am: New file.
This is ok, but...
Akim> -push (@suffixes, $lex_suffix);
again, isn't removing this wrong?
I thought maybe there would be code in &file_cont
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&make_paragraphs): Transform TOPDIR_P and TOPDIR.
Akim> (&handle_dist): Don't.
Akim> (&handle_clean): Don't handle config.status here, let...
Akim> * clean.am: ... do it.
Akim> * distdir.am: Adjust.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> In fact, since I wrote that patch, I learned about objects in Perl,
Akim> and given that Automake, IMHO, lacks of modularity, I started toying
Akim> with languages implemented as objects. Then there is no longer any
Akim> reason to
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in: Use strict vars and subs.
Akim> Declare `%require_file_found'.
Akim> (&handle_source_transform, &make_paragraphs): Declare my variables.
Ok.
Tom
> "Jim" == Jim Meyering <[EMAIL PROTECTED]> writes:
Jim> * missing (--run): Use `eval' to run `"$@"'. Otherwise, Ultrix4.4's
Jim> /bin/sh fails and outputs garbage.
Jim> - "$@" && exit 0
Jim> + eval "$@" && exit 0
I read through this thread but didn't see convergence on a solution.
Do we
> "Lorenzo" == Lorenzo Bettini <[EMAIL PROTECTED]> writes:
Lorenzo> I'd like to include two of my programs java2html and cpp2html
Lorenzo> into the same package (say src2...), but I would like to
Lorenzo> maintain two different program names and versions, and
Lorenzo> moreover I'd like to hav
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
Derek> FYI: the *.cps & *.fns files are only being created for cvs.texinfo.
Did we ever get some resolution for this?
Akim, I recall you had a patch which removed a large number of file
extensions from the texinfo clean list. Perhaps
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> CVS Automake uses am_line_error() to inform the user that it's
Pavel> installing files. As a result, --Werror causes Automake to exit
Pavel> after it installs the first file:
I submitted a PR about this in your name.
Thanks.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * data.am, header.am, java.am, libs.am, lisp.am, ltlib.am,
Akim> * progs.am, python.am: Use if/endif instead of ?INSTALL?.
Akim> * java.am (_am_installdirs): Be sure to set it.
Ok. Thanks.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> So from now on, `FALSE' is used where ever a condition is needed, and
Akim> `#' where ever a Make condition is needed. Of course `#' should not
Akim> be actually output, but why making weak code instead of robust code.
I'm not sure
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&make_condition): Return '#' when FALSE.
Akim> (&conditional_string): Return FALSE, not '#' in the corresponding
Akim> cases.
Akim> (&file_contents_internal): Adjust.
Akim> (&check_variable_defined_unconditio
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * distdir.am: Use and abuse of if/endif.
Akim> * scripts.am: Using if/endif with variables is fine.
Ok.
This is nice.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&make_paragraphs): Extract from &file_contents.
Akim> Make it more robust than the previous RE based scheme.
Akim> (&file_contents): Use it.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> There is still one test which fails, but it's because I don't
Akim> know what happens: subobj2.test.
Consider this code in depend2.am:
?AMDEP?@AMDEP@%FPFX%DEPMODE = @%FPFX%DEPMODE@
We include depend2.am once per extension. Bu
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> I must say I don't understand very well why this patch is
Akim> needed, but it is. I found it back in the old code, which was
Akim> doing it for unconditionally defined sources, but not for
Akim> conditionally defined sources (which
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> I had to write this one under the pressure of variable_define
Akim> which doesn't want one variable to be defined several times.
Akim> Given that it was due to a hack, fixing it using the regular
Akim> mechanism seems the right choic
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> + * automake.in (&variable_define): The user is allowed to override
Akim> + a value if it was set by Automake, or if it was found in AC_SUBST.
Akim> Still polishing permissions rules.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&handle_source_transform): Better locality of the
Akim> variables.
Akim> Use `next' to skip nonexistent variables.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&variable_dump): If a variable is undefined, say
Akim> it.
Akim> (&check_ambiguous_conditional): Give finer error messages.
Akim> (&variable_define): Check that a `+=' variable is not set with `='.
Akim> Chec
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Handle unconditional values of variables as conditioned by
Akim> `TRUE'.
Akim> * automake.in (%contents): Remove.
Akim> (&generate_makefile, &handle_ltlibraries, &variable_define)
Akim> (&read_am_file, &variable_defined, &v
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> The point of this patch and the next ones is to have a unified
Akim> handling of all the kinds of variables. Before this patch,
Akim> variables have their `constant' value in %content, and
Akim> conditional vars have their content a
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&variable_defined): Some callers, e.g.,
Akim> &am_primary_prefixes, really want to know if the variable is
Akim> defined for any condition, not `TRUE' by default.
Akim> (&am_primary_prefixes): Give a more preci
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * tests/defs, tests/depend3.test: Remove useless code.
Ok.
I think this one falls under the "obvious fix" rule.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&variable_conditions_reduce): FALSE is absorbent.
Akim> (&variable_conditions): Don't include `FALSE' in the result.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&handle_source_transform): Use
Akim> &variable_conditions, don't read $conditional{$var}.
Akim> (&variable_conditions_sub): When the call is the top level call,
Akim> generate all the permutations of the condi
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * depend2.am (@AMDEP@%FPFX%DEPMODE): Define it when GENERIC so
Akim> that it does not get noticed twice by automake, which now
Akim> complains for multiple definitions.
Akim> * tests/vartar.test: s/INSTALL/install/g, automake
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&read_am_file, &file_contents): Avoid name clashed
Akim> on $cond.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&generate_makefile) Use variable_define to define
Akim> SOURCES and OBJECTS.
Akim> (&variable_defined): Don't check for $conditional{VAR}{COND} as
Akim> this would make perl create $condition{VAR}, which we don
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> + * automake.in (&variable_defined, &define_pretty_variable):
Akim> + Simplify code which used to handle the cases where not all
Akim> + variables were in %conditional.
Akim> + (&define_variable): Use &define_pretty_variable.
Akim> +
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> This patch and a couple of following patches are breaking
Akim> Automake. That was the easiest path to finish cleaning up the
Akim> variable handling. This series of patches ends with patches
Akim> that fix some of these issues.
A
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&handle_source_transform, &read_main_am_file):
Akim> Simplify loops which were split in two parts, conditional vs
Akim> unconditional variables.
Ok.
Tom
> "Hari" == Raja R Harinath <[EMAIL PROTECTED]> writes:
Hari> Try changing that to
Hari> sed 's/^.*\.o://' | tr '
I checked this in.
Thanks.
Tom
> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
Robert> 1) The
Robert> http://www.gnu.org/manual/automake/html_mono/automake.html
Robert> documentation implies that _SOURCES can take the same style of
Robert> late bound entries as _PROGRAMS and _LIBRARIES can, as long as
Robert> EXTR
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
Derek> One of the other CVS developers reported a bug in depcomp on
Derek> BSD/OS. Apparently the included /bin/sh doesn't set $? inside
Derek> of the conditional. His original message and fix are attached.
I checked in a variant of th
> "Raja" == Raja R Harinath <[EMAIL PROTECTED]> writes:
Raja> Whoops. I forgot all about that. I was thinking of
Raja> foo.o bar.o: %.o: %.h; ...
Multiple ":"s can appear on a line when using Windows, too.
Raja> Anyway, we are getting off-topic :-) The 'sed' rule under
Raja> question is
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> I'd be happy to clean this, but there is already quite a few
Akim> patches in the queue :( TODO?
Send in a PR.
Tom
> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
>> Were they also listed in another foo_SOURCES variable?
>> That would cause them to end up in the dist.
Robert> Yes they were. I didn't know you could do
Robert> BUILT_foo_SOURCES. I'll try rearranging the targets like that
Robert> a
> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
Robert> Now automake --foreign in the root of the source tree (uhmm,thats
Robert> ../../../../../ ) complains about a missing compile
Robert> script. --add-missing installs compile in the leaf branch.
Robert> Commenting out the _CFLAGS
> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
>> BUILT_SOURCES aren't automatically distributed.
Robert> Well... it was trying to :]. I've sent in an extract from
Robert> Makefile.am,, would you like a test case?
Sure.
Were they also listed in another foo_SOURCES variable?
That
Tom> I'm suprised by that. I thought we were always building as
Tom> foo.$(EXEEXT). That's why we did the ugly _PROGRAMS rewrite
Tom> stuff in am_install_var.
Akim> As a matter of fact we do rewrite *_PROGRAMS, but *after* having
Akim> set @result which is the return value of am_install_vars.
A
Robert> AC_EXEEXT was already present. I added AC_OBJEXT and ran
Robert> automake --foreign again, no change.
Akim> Sorry, I think I was confused. I checked, and it seems to be
Akim> what was designed: compile as foo, but *install* as
Akim> foo.$(EXEEXT). I might be wrong again, but at least 1.
> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
Robert> squid_SOURCES = \
Robert> access_log.c acl.c asn.c auth_modules.c authenticate.c cache_cf.c
Robert> cf_parser.h \
Robert> disk.c @DNS_SOURCE@ errorpage.c
You can't use a configure substitution in a _SOURCES variable.
This is a
> "Esben" == Esben Haabendal Soerensen <[EMAIL PROTECTED]> writes:
Esben> The automake docs claims that the ylwrap script solves the
Esben> problem with including multiple yacc or lex source fles in a
Esben> single program, but it seem to only solve a very small part of
Esben> the problem.
T
> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
Robert> However there is still a problem:
Robert> make dist doesn't create directory foo.
This is a bug.
>> 2) Do the stub directories such as foo, which only have 2 or three c
>> files need Makefile.am's ?
Robert> I take it the answ
Alexandre> There's an automake option that tells it to keep object
Alexandre> files in subdirs. I don't recall the exact spelling.
Akim> Couldn't find it in the doc (probably still too experimental?),
Akim> but a RTFC shows it's subdir-objects. See the subobj*.test
Akim> files.
That's a genero
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Robert> is there some way to exclude specific built sources from the
Robert> disrtribution?
Akim> Automake will always ship parsers and scanners, but I don't
Akim> believe it ships all the BUILT_SOURCES.
BUILT_SOURCES aren't automaticall
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> I'm leaving the text of your email intact for the benefit of new
Gary> readers on [EMAIL PROTECTED] It appears that the problems you
Gary> are experiencing are caused by the automated compiler dependency
Gary> generation code in au
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
Derek> One of the other CVS developers reported a bug in depcomp on
Derek> BSD/OS. Apparently the included /bin/sh doesn't set $? inside
Derek> of the conditional. His original message and fix are attached.
Thanks. This looks good to
> "Naveen" == Naveen Chandra <[EMAIL PROTECTED]> writes:
Naveen> I am using gnu tools to configure my build environment. If I run
Naveen> automake --foreign --include-deps I get an error
Naveen> "automake: no `Makefile.am' found or specified" eventhough I have
Naveen> Makefile.am. I have l
601 - 700 of 1294 matches
Mail list logo
