[shell functions, was RE: solving of name conflicts in included . a]

[Boehne, Robert]

Jan,

That actually brings up a big issue.  I *assumed* that the win32 patches
using shell functions that were checked in would only have shell functions
when running under windows.  I later saw this was not the case.  There has
been a large amount of debate over this in the Autoconf list, which I do
not care to repeat here.  There are systems that do not have shell functions
in their bourne shells, this is a known fact.  The decision to support them
was made a long time ago, and as time progresses it seems to make less sense
to support aging systems like this.  However, I do not want Libtool to get
out of sync with Autoconf, suddenly not running on systems where Autoconf
does run.  Frankly, I don't see the point of shell functions in this case
because we use m4.  The solution I would propose is to turn your shell functions
into m4 macros where possible, and any WIN32 specific code can be only included
when WIN32 is detected at run time
(via ". some_here_document_containing_win32_shellfuncs")
Until all the Autotool maintainers decide to abandon support for non-shell function
bourne shells we need to support them as well.  The Autoconf maintainers recently
decided against this, and keeping compatibility with Autoconf is a primary concern.
  I vote to revert the patches that use shell functions, preferring to include
them only on systems known to use them (like win32).  The patch resolving name
conflicts in archive libs could be converted to m4, or just included in
the necessary spots.
  Considering the relative ease that these changes could be done with, I don't
think it makes sense to drop any platform for this reason.

Ok, let the flame wars begin...

Robert

-----Original Message-----
From: Jan Kratochvil
[mailto:address@hidden]
Sent: Thursday, November 07, 2002 9:19 AM
To: Boehne, Robert
Cc: address@hidden
Subject: Re: solving of name conflicts in included .a

Robert,

On Thu, 07 Nov 2002 15:52:10 +0100, Boehne, Robert wrote:
...
> I haven't gone over your patch with a fine-toothed comb, but
> the idea works for me.

Akim Demaille noted the problematic use of shell functions but one function was
already there before my patch anyway. BTW I found out you are using the same
code many times over the code - would not it be better to preprocess the
file(s) with some preprocessor if you want to prevent shell functions?

> I checked but couldn't find your name
> in the copyright assignment list.  Would you be willing to
> assign the copyright for your changes over to the FSF?

I agree to assign my copyright / authorship of my patch identified by
MD5 55fe631a9b5a634f1366a8e4f68f7a1c (with LF newlines) to FSF.
This contract is concluded according to U.S. law.
(The laws of Czech Republic do not permit authorship assignment and therefore
it must be done by special contract about rights extensions/restrictions of the
involved two parties on the specified subject (program).)

Regards,
Lace