RE: [Patch] skipping import libraries for performance reasons - direct auto-import of dll's

["Ralf Habacker" <Ralf dot Habacker at freenet dot de>]

> All well and good, Ralf, but Chris' comment grew out of your policy
> recommendations about *removing* the existing import lib support that
> libtool currently provides.   I know, you probably don't think you did
> that -- but you said your new change would simplify libtool.

Chuck, thank you for clearing this. Yes you're right, I have said this.

> This clearly means you assume that newlibtool would only support your schema,
> since supporting both current-schema and ralf-schema is OBVIOUSLY more
> complicated that the existing libtool code, and you wouldn't make the
> mistake of thinking that supporting both would somehow simplify libtool.

Your right too. I have forgotten about this two way support.
My focus was basically by the qt and the kde port, where this schema save a lot
time, which could be used more usefull.

Sorry for confusion, especially to Chris.

> Then Chris pointed out that libtool MUST continue to support existing
> schema, which means that your proposal could only be supported by making
> libtool more complicated.  You argued that old schema no longer
> necessary, therefore it could be dropped (thus simplifying libtool).
> cgf said no, what about cygwin1.dll's import library (and others like it).
>
For which I have asked, where the problems are to divide it.

> Everybody agrees that your new change -- if it works in all cases and
> doesn't break existing stuff -- is a good contribution, and should be
> added to ld.  Chill.
>
> The only question is, Shall the cygwin community enforce this new usage:
> import libs are (in general) merely symbolic links to the runtime dll.
>
> I think the answer is no -- cygwin shouldn't *enforce* anything of the
> sort.  But, it deserves a mention on the "How do I build a DLL" page.  I
> should probably put an example of that method in my dllhelpers package.
>   Maybe down the road, libtool could make "import libs" that way,
> provided a certain switch is given.   Even further down the road, maybe
> that could become the libtool default.
>
I agree.

> But no coercion.  No enforcement.

This is not my intention.

> Just, "here's a nifty feature that'll
> speed things up and cut down on memory usage when linking."  If it's a
> marked improvement over current state of the art, it will (eventually)
> win.  There's no need to change any policies, IMO.

Althougth for me is it sometime unexplainable, why some features are accepted
and some not.
This "eventually" makes it much more hard for contribution and a little bit
clearence of this would make it easier.
I remember at least two (i find useful) patches I submitted to cygwin (ssp time
stamp printing and additional import libraries for cygwin for example libdl),
which are not applied until now. Because this patches (at least the first) has
required noteworthy effort, which I don't like to see going into the trash.

I don't like to moan about something, but I think there are some improvement
possibility especially for people, who does not contribute every day. But this
is another thread, so I will stop here.

> But first step is to just get the **** feature into binutils.  I know
> you're waiting on my testing, but I can't do that until the Thxgvng
> holidays.
>
Okay, I will wait for your results. :-)



Ralf


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/