Okay to apply to branch-1-5 and then forward port?
Peter
--
Peter O'Gorman - http://www.pogma.com
Index: ChangeLog
2005-02-24 Peter O'Gorman <[EMAIL PROTECTED]>
* libtool.m4: The compiler can be a program name with args, so
always check cc_basename against compiler name and a wil
On Thu, 24 Feb 2005, Peter O'Gorman wrote:
Okay to apply to branch-1-5 and then forward port?
Doesn't it make most sense to fix cc_basename so that it doesn't
include any trailing cruft? Then the switch would not need to be
changed. The wildcard might match a command name which differs by
late
Hi Peter!
Bob Friesenhahn wrote:
> On Thu, 24 Feb 2005, Peter O'Gorman wrote:
>
>> Okay to apply to branch-1-5 and then forward port?
>
> Doesn't it make most sense to fix cc_basename so that it doesn't include
> any trailing cruft? Then the switch would not need to be changed. The
> wildcard
Gary V. Vaughan wrote:
Doesn't it make most sense to fix cc_basename so that it doesn't include
any trailing cruft? Then the switch would not need to be changed. The
wildcard might match a command name which differs by later characters.
My thoughts exactly. cc_basename is only ever used in case
>> cc_basename=`$echo X"$compiler" | $Xsed -e 's%^.*/%%;s%[ ].*$%%'`
Make that:
cc_basename=`$echo X"$compiler" | $Xsed -e 's%^.*/%%;s%[ ]*.*$%%'`
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU
Hi guys,
* Gary V. Vaughan wrote on Fri, Feb 25, 2005 at 01:21:14PM CET:
> Bob Friesenhahn wrote:
> > On Thu, 24 Feb 2005, Peter O'Gorman wrote:
> >
> >> Okay to apply to branch-1-5 and then forward port?
> >
> > Doesn't it make most sense to fix cc_basename so that it doesn't include
> > any tr
Ralf Wildenhues wrote:
> Hi guys,
Hallo Ralf!
Welcome back :-)
> * Gary V. Vaughan wrote on Fri, Feb 25, 2005 at 01:21:14PM CET:
>
>>Bob Friesenhahn wrote:
>>
>>>On Thu, 24 Feb 2005, Peter O'Gorman wrote:
>>>
>>>
Okay to apply to branch-1-5 and then forward port?
>>>
>>>Doesn't it make most
Hi Gary,
* Gary V. Vaughan wrote on Tue, Mar 01, 2005 at 02:04:51PM CET:
>
> Welcome back :-)
Thanks! (freezing)
> > * Gary V. Vaughan wrote on Fri, Feb 25, 2005 at 01:21:14PM CET:
> >>Bob Friesenhahn wrote:
> >>
> >>My thoughts exactly. cc_basename is only ever used in case statements,
> >>s
Hallo Ralf!
Ralf Wildenhues wrote:
>>>You guys ever encountered a system with compilers named
>>> gcc-3.4.1
>>> gcc-3.4.2
>>> icc-8.1
>>> ...
>>
>>Yep, but you would need to build a different libtool for each compiler.
>>Relying on the compiler checks performed on one working for another is
>>
On Tue, 1 Mar 2005, Gary V. Vaughan wrote:
You guys ever encountered a system with compilers named
gcc-3.4.1
gcc-3.4.2
icc-8.1
...
Yep, but you would need to build a different libtool for each compiler.
Relying on the compiler checks performed on one working for another is
likely to cause t
On Tue, 1 Mar 2005, Ralf Wildenhues wrote:
Sure. But we are talking about m4/libtool.m4, right?
This happens at configure time.
I want, in a libtoolized project,
../configure CC='pgcc-78.9 -foo-option'
to succeed in choosing Portland compiler options. No multiple compilers
involved here.
Libtool
Bob Friesenhahn wrote:
I want, in a libtoolized project,
../configure CC='pgcc-78.9 -foo-option'
to succeed in choosing Portland compiler options. No multiple compilers
involved here.
Libtool also lives as a stand-alone utility, which may be installed!
I am going to stand up again (because I lik
Gary V. Vaughan wrote:
Ah yes. Thinko. Currently we should recommend:
../configure CC='/opt/pgcc-78.9/bin/pgcc -foo-option'
But, I agree that supporting multiple compilers in users' PATH is also
a nice feature. Like you said, "let's do both!" :-) We'll need an
entry in sh.test to spot switche
* Peter O'Gorman wrote on Wed, Mar 02, 2005 at 02:33:38PM CET:
> Bob Friesenhahn wrote:
> >>I want, in a libtoolized project,
> >> ../configure CC='pgcc-78.9 -foo-option'
> >>to succeed in choosing Portland compiler options. No multiple compilers
> >>involved here.
> >
> >Libtool also lives as a s
Hi Gary, Peter,
* Gary V. Vaughan wrote on Tue, Mar 01, 2005 at 03:43:04PM CET:
> Ralf Wildenhues wrote:
> >
> > Sure. But we are talking about m4/libtool.m4, right?
> > This happens at configure time.
> >
> > I want, in a libtoolized project,
> > ../configure CC='pgcc-78.9 -foo-option'
> > t
On Wed, 2 Mar 2005, Peter O'Gorman wrote:
Bob Friesenhahn wrote:
I want, in a libtoolized project,
../configure CC='pgcc-78.9 -foo-option'
to succeed in choosing Portland compiler options. No multiple compilers
involved here.
Libtool also lives as a stand-alone utility, which may be installed!
I
On Mar 2, 2005, "Peter O'Gorman" <[EMAIL PROTECTED]> wrote:
> I am going to stand up again (because I like being shot down) and ask
> if the "stand alone utility" bit is really necessary.
I wish it would just go away, or be properly implemented. I see so
many people being bitten by this that ev
On Wed, Mar 02, 2005 at 03:38:58PM -0300, Alexandre Oliva wrote:
> On Mar 2, 2005, "Peter O'Gorman" <[EMAIL PROTECTED]> wrote:
>
> > I am going to stand up again (because I like being shot down) and ask
> > if the "stand alone utility" bit is really necessary.
>
> I wish it would just go away, o
Albert Chin wrote:
> On Wed, Mar 02, 2005 at 03:38:58PM -0300, Alexandre Oliva wrote:
>>
>>Until we get as far as implementing something that enables us to use
>>the pre-installed libtool properly, which implies doing configuration
>>on-the-fly, recognizing ABI-changing flags and all such tricky st
Gary V. Vaughan wrote:
+0.5 to remove installed libtool script in HEAD
-0.5 for branch-2-0
-1 for branch-1-5
-1 HEAD
-1 branch-2-0
-1 branch-1-5
I have a few concerns about removing this functionality: namely, I
maintain a bunch of cygwin packages, and some of those use libtool but
not automake
On Thu, Mar 03, 2005 at 12:52:14AM +, Gary V. Vaughan wrote:
>
> I never use the installed libtool myself, and can't think of a
> compelling reason to keep it around that outweighs the
> misunderstandings that it causes.
Is `libtool --mode=execute gdb ...' subject to the errors you are
discuss
Salut Alexandre!
Alexandre Duret-Lutz wrote:
> On Thu, Mar 03, 2005 at 12:52:14AM +, Gary V. Vaughan wrote:
>
>>I never use the installed libtool myself, and can't think of a
>>compelling reason to keep it around that outweighs the
>>misunderstandings that it causes.
>
>
> Is `libtool --mod
Hi Chuck,
Charles Wilson wrote:
> Gary V. Vaughan wrote:
>
>> +0.5 to remove installed libtool script in HEAD
>> -0.5 for branch-2-0
>> -1 for branch-1-5
>
>
> -1 HEAD
> -1 branch-2-0
> -1 branch-1-5
>
> I have a few concerns about removing this functionality: namely, I
> maintain a bunch of
On Thu, 3 Mar 2005, Gary V. Vaughan wrote:
Very well, then let's put it to the vote! I never use the installed
libtool myself, and can't think of a compelling reason to keep it around
that outweighs the misunderstandings that it causes. But, on the other
hand I'm not sure I want to rock the boat
On Thu, Mar 03, 2005 at 01:49:20AM -0500, Charles Wilson wrote:
> I have a few concerns about removing this functionality: namely, I
> maintain a bunch of cygwin packages, and some of those use libtool but
> not automake (nor, in one case, autoconf). Namely, libjpeg(*) and
> ncurses; I'm sure t
On Mar 3, 2005, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> In making this decision, we must consider what existing Automake
> does. If it searches for installed libtool by looking for a 'libtool'
> program in the path, then there will be problems.
Automake uses libtool the way it was designed
On Thu, 3 Mar 2005, Alexandre Oliva wrote:
On Mar 3, 2005, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
In making this decision, we must consider what existing Automake
does. If it searches for installed libtool by looking for a 'libtool'
program in the path, then there will be problems.
Automake us
On Mar 3, 2005, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> I was thinking about how configure often searches for autoconf and
> automake in order to maintain the package. I guess it does not search
> for libtool since libtool files are not automatically maintained.
Right. This works as long
Hi Peter,
I answered already in another mail, but since replying to several mails
at once is not always easy to spot:
* Peter O'Gorman wrote on Wed, Mar 02, 2005 at 02:29:20PM CET:
> Gary V. Vaughan wrote:
>
> >Ah yes. Thinko. Currently we should recommend:
> >
> > ../configure CC='/opt/pgcc-
I need this patch.
* Ralf Wildenhues wrote on Mon, Mar 14, 2005 at 07:46:06PM CET:
> * Peter O'Gorman wrote on Wed, Mar 02, 2005 at 02:29:20PM CET:
> >
> > I'm confused as to whether all this means that my original patch is
> > acceptable or not :)
>
> Yes, your original patch is acceptable, but
To finish this up for now..
* Gary V. Vaughan wrote on Tue, Mar 01, 2005 at 03:43:04PM CET:
> Ralf Wildenhues wrote:
> > I want, in a libtoolized project,
> > ../configure CC='pgcc-78.9 -foo-option'
> > to succeed in choosing Portland compiler options. No multiple compilers
> > involved here.
>
Hallo Ralf!
Ralf Wildenhues wrote:
> OK to apply the patch below (HEAD, branch-2-0)?
> The sh.test test is by no means perfect (it will miss errors on lines
> with more than one pattern), but better than nothing, and seems to be
> portable.
Indeed, I would have written something no more complex t
* Gary V. Vaughan wrote on Mon, Mar 21, 2005 at 03:11:00PM CET:
> Ralf Wildenhues wrote:
> > OK to apply the patch below (HEAD, branch-2-0)?
> > The sh.test test is by no means perfect (it will miss errors on lines
> > with more than one pattern), but better than nothing, and seems to be
> > portab
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gary V. Vaughan wrote:
| Very well, then let's put it to the vote! I never use the installed
| libtool myself, and can't think of a compelling reason to keep it around
| that outweighs the misunderstandings that it causes. But, on the other
| hand I'm
34 matches
Mail list logo
