|
|
In article <87myokrucw.fsf@xxxxxxxxxxxxxxx>,
Keith Thompson <kst-u@xxxxxxx> wrote:
>Unconditionally adding the ".exe" suffix in runtests would fix that
>problem, but it would be an ugly solution, since Unix doesn't require
>a ".exe" suffix on executables (and adding one is, in my opinion and
>apparently in Chuck's, poor style). I understand that in the djgpp
>environment, the ".exe" suffix is required but needn't be specified
>when executing a command; Cygwin works the same way, as does plain
>Windows.
>
>A better solution would use the ".exe" suffix where it's required, and
>not use it where it isn't.
>
><OT>Probably the best way to do that would be to define a variable in
>the makefile whose value is either ".exe" or "" depending on the
>system. The method for doing this, particularly for determining which
>system you're on, is left as an exercise. A simpler brute-force
>solution would be to provide two (or more) makefiles.
An intermediate between those is to localize the bits that need to
change between systems into a bunch of definitions in one place, and
have everything else use those definitions.
<pseudo-topicality type="stretched">This is much the same way
mostly-portable C programs that depend on interfacing to non-portable
system features can be written.</>
My makefiles collect rules for converting base names into executable
names, object file names, library file names, and command-line
arguments for referring to all of those (along with a few other things
that globally influence the build, like compiler flags), into
build-config.mk.<system>; then building on a different system just
requires copying or symlinking build-config.mk.<system> to
build-config.mk, and (if I've gotten things abstracted correctly, which
can take a while to get sorted out) the makefile that includes that
Just Works.
> </OT>
dave
--
Dave Vandervies dj3vande at eskimo dot com
Either that, or %s is the nearest he can come using ascii to his
native-language term for "hedgehog" ...
--Chris Dollin in comp.lang.c
|
|