[Top][All Lists]

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

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

From: Charles Wilson
Subject: Re: [shell functions, was RE: solving of name conflicts in included . a]
Date: Thu, 07 Nov 2002 12:42:46 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2

Boehne, Robert wrote:

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.

No flames from me. I actually brought this issue up when I submitted my patches:

Charles Wilson wrote:

Since $file_magic_cmd is called with different arguments ($file_magic_test_file in one place, \"\$potlib\" in another), we need some construct that can take an argument, and then run a sequence of shell commands on it. The only choices I see are a shell function, or use a HERE document to generate an ancillary script.

Seems like a shell function is the obvious choice -- but I notice that libtool doesn't seem to use them. Is there a policy against shell functions? (I hope not...)

I can rework the patch as needed to support Robert's proposed change, but what is the best way to do that? A separate script that is installed by libtoolize alongside (on all platforms), or a here doc that is generated during configure?

And what if you're trying to build for cygwin, using a cross compiler on buildhost X? We need the shell function/external script when building FOR cygwin, but the buildhost's shell might not support them...

Now, we can simply say: cygwin targetted cross compilers using libtool are not supported on ancient hosts with no shellfunction support.

Or, every "shell function" can be a separate script...blech. See Paragraph 1 above.

I'm sorry to see that the autoconf people have decided against shell functions, but I agree that libtool needs to remain "at the same level" as autoconf. So, if autoconf doesn't use 'em, neither should we (except in special circumstances, rigidly separated from "general" use. E.g. Robert's "separate file" solution.)

Point of order: the shell function needed for windows support is not *used* (e.g. called) by any other platform. However, as currently configured it is *parsed* on every platform -- thus leading to errors on those platforms whose shells don't support shellfunctions.


reply via email to

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