automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: superfluous link rule for unknown languages


From: Alexandre Duret-Lutz
Subject: Re: superfluous link rule for unknown languages
Date: 06 Jul 2001 11:40:05 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

>>> "Tom" == Tom Tromey <address@hidden> writes:

 >>>>>> "adl" == Alexandre Duret-Lutz <address@hidden> writes:
 Tom> I think the best fix is to go back to conditionally using $(EXEEXT).

 adl> Wow, this is really different from any fix I would have
 adl> imagined.  (From my point of view Automake should not emit a
 adl> link rule for unknown languages, but maybe that would be a
 adl> feature and it's not time for this.)

 Tom> I think it's hard to classify this one.  Historically automake just
 Tom> went ahead and generated a rule unless the user did it.
 Tom> The user could also affect it by setting program_LINK (this is still
 Tom> undocumented!  I'll fix) if he wanted most of the rule.
 Tom> I'm inclined to keep doing this, as it is backwards-compatible.
 Tom> Also it doesn't seem obviously wrong.  Many times an unknown extension
 Tom> is just translated to C and using the "C linker" is appropriate.

In my case it's not appropriate.  The source of my program is
another program :).  This is the kind of setup I use to build a
PalmOS application: 1) generate a binary from the sources, using
gcc; 2) create the actual Palm application by merging the
aforementioned binary and several data files, using build-prc.

| noinst_PROGRAMS= tlp224e
| tlp224e_SOURCES= jumptable.c tlp224e.c tlp224e_bits.h debug.c debug.h
| 
| bin_PROGRAMS= tlp224e.prc
| tlp224e_prc_SOURCES= tlp224e.def tlp224e-in.rcp
| 
| tlp224e.prc: $(srcdir)/tlp224e.def tlp224e resources-stamp
|         $(BUILD_PRC) $(srcdir)/tlp224e.def tlp224e $(RSC_DIR)/*.bin

The above works fine with Automake 1.4.  With Automake 1.4h I
need to change it as follow, so that no link rule get
generated (and it's still compatible with 1.4, that's a
requirement for me).

| noinst_PROGRAMS= tlp224e
| tlp224e_SOURCES= jumptable.c tlp224e.c tlp224e_bits.h debug.c debug.h
| 
| prcdir= @bindir@
| prc_DATA= tlp224e.prc
| EXTRA_DIST= tlp224e.def tlp224e-in.rcp
| 
| tlp224e.prc: $(srcdir)/tlp224e.def tlp224e resources-stamp
|         $(BUILD_PRC) $(srcdir)/tlp224e.def tlp224e $(RSC_DIR)/*.bin

Yet this is quite hairy, tlp224.prc really is a program not data.

 adl> I see $seen_exeext is set to 1 when Automake encounter
 adl> AC_EXEEXT.  AC_EXEEXT has been obsoleted in Autoconf 2.50 which
 adl> now always compute EXEEXT.  Isn't this why Automake
 adl> unconditionnaly used $(EXEEXT) ?

 Tom> Yes.  And this means that if you are using autoconf 2.50 then you must
 Tom> write the target as `prog$(EXEEXT)'.

Precisely I don't think it's true with this fix you have checked
in.  Now you should write `prog$(EXEEXT)' only if Automake see
AC_EXEEXT.  But since AC_EXEEXT is *implicit* in Autoconf 2.50,
Automake will never see AC_EXEEXT.

 Tom> Anything else would be incorrect, I think.  I've made a
 Tom> note so that I'll be sure to document this.  This is a bit
 Tom> ugly.  Do you think there is something better?

Can't Automake be tweaked so that it recognizes `mumble' and
`mumble$(EXEEXT)' are the same targets ?  Maybe it's as simple
as ignoring '$(EXEEXT)' in the $RULE_PATTERN regex.
-- 
Alexandre Duret-Lutz



reply via email to

[Prev in Thread] Current Thread [Next in Thread]