Re: program target missing $(EXEEXT)

[edward]

yep. progs.am, for example. has tons of unix specific stuff like rm -f. i
think it'll take a bit of abstraction (read: a lot of abstraction) and
modification to automake to get to the point where exe type platforms are as
easily used as unix type platforms.

the problem with the kind of patches i've posted is that it's so cygwin
specific. philosophically, i too would prefer to remain platform neutral as
much as possible. perhaps the usage of modules to break out the platform
specific stuff?

not sure what a good approach would be. i'm willing to help out in ways that
i can. i just think automake/autoconf/libtool are starting to bring a lot of
"fat" to the table. given that they are often used together *but* are also
used apart, it's a pretty steep challenge to manage.

here is the current situation as i see it. some apps like gcc can manage
.exe by themselves. others like "install" handle .exe differently in
specific cases. others like "rm" don't handle .exe at all (and shouldn't).
automake deals with this by explicitly adding .exe (basically everywhere).

however, downstream development utilities like libtool *expect* the .exe to
*not* be explicitly tagged in the Makefiles. having .exe breaks libtools
usage of scripts to wrap applications which need a loader hint (for dll
path). unfortunately, creating a script called foo.exe wreaks havoc on
windows systems, at least. which try to load it (kids don't try this at home
:)

so, what do all you automake peeps suggest?

cheers,
edward

----- Original Message -----
From: "Robert Collins" <address@hidden>
To: "edward" <address@hidden>; "Akim Demaille" <address@hidden>
Cc: <address@hidden>
Sent: Tuesday, March 27, 2001 8:43 PM
Subject: RE: program target missing $(EXEEXT)


> -----Original Message-----
> From: edward [mailto:address@hidden
> Sent: Wednesday, March 28, 2001 11:27 AM
> To: Robert Collins; Akim Demaille
> Cc: address@hidden
> Subject: Re: program target missing $(EXEEXT)
>
>
> yep. enclosed is a patch which demonstrates how i deal with that. the
> *first* set of unidiff marked is the part that came up as
> unacceptable.
> unfortunately, the rest really don't work w/o it. the 2nd
> unidiff marked is
> something i'm trying to track down. that is, how to deal properly with
> SUFFIXES = and extension map. so please ignore. the rest is really the
> "meat" of how i'm currently (brokenly in terms of philosophy,
> but it *does*
> work) handling exe. this patch is mostly meant as a
> conceptual demonstration
> more than anything else.
>
> generally, i only re-write the rules that require it. for
> example, gcc on
> wintel is .exe aware. unfortunately, rm isn't. so clean
> targets need to be
> updated. it's pretty important to keep the bin targets free
> of .exe however,
> if you want to use libtool for creating dlls and apps that use dlls.

I still have a philosophical issue here. You're handling "known
programs". I really think the right way to do this is handle "known
platforms". Compilers on cygwin/mingw/os2/dos that need .exe are the
rule not the exception. To pick an example, rm, if the user is on mingw,
that won't be rm, it'll be "$(SHELL) delete". What then?

Rob

> cheers.
>
> --- automake.in.~1.995~ Mon Mar 26 21:31:18 2001
<skip>