Dave Korn wrote:
>> This part is messy -- and unnecessary for the intended use case. In gcc,
>> all you need to do is explicitly modify the Makefile.am's to pass the
>> necessary option. You don't need to do anything to automake or
>> libtoolize, AFAICT.
>
> That's actually my /real/ plan for GCC, but I figured at some point it would
> be a nice extension to do it automatically.
Right, which is why I asked Yaakov about his specific use cases. If he
had 200 instances, then adding --bindir=\${bindir} to libfoo_la_LDFLAGS
as a private cygwin patch, or officially upstream in 200 project foo's
would be...problematic. With just two or three, then a gradual
approach, adding --bindir to libtool first, and then later adding
support if necessary to automake, becomes feasible.
OTOH, Dave, can you see any reason why Yaakov's simpler "hack" as
modified by your 19:21:26UTC message shouldn't *ALSO* go in, along with
--bindir support? It (1) seems like a reasonable approach, (2) doesn't
suffer from the "hey that dir doesn't exist yet" problem, and (3)
doesn't appear to have much potential for causing harm in normal usage.
It doesn't solve your gcc problem[*], but won't interfere with it,
either -- espeically if you modify gcc to explicitly use the new
--bindir support.
[*] actually, it might: /usr/lib/gcc/i686-pc-cygwin/4.3.2/ *is* in a
subdir of THE $libdir...so Yaakov's approach will turn
/usr/lib/gcc/i686-pc-cygwin/4.3.2/
into
/usr/lib
and append a ../bin to it -- which works if THE $libdir and THE $bindir
are actually siblings. Since, for gcc, they may not be, --bindir is
actually a cleaner approach in that case. But in general,...
--
Chuck
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
