Mail Archives: cygwin-apps/2002/05/20/07:44:02
> -----Original Message-----
> From: Charles Wilson [mailto:cwilson AT ece DOT gatech DOT edu]
> Sent: Monday, May 20, 2002 6:44 PM
> Two ideas:
> 1) making auto-import the default
> 2) turning off the warnings
>
> You appear to not like either one. I don't really care about the
> warnings, but the auto-import thing should be default. However, I
> wonder how long these "warnings" are going to persist. Using
> auto-import is not a *bug* or *oops, I forgot to declspec()
> something*
> -- it's the way DLLs are done.
But it's not complete. One cannot link against all .dll's with
auto-import, and no speed tests of normal vs auto-import have been
seriously conducted. I still maintain that a profile driven
recompile+link is the way to go, and that when that's done auto-import
can be tossed out.
> I look at auto-import as "the new and better and more unixlike way of
> building shared libs". You seem to view them as "nice
> feature, but you
> really ought to do it the old-fashioned way". In my view,
> the warnings
> go away eventually -- they were just there during the "trial phase",
> which has now stretched to a REALLY long time. In your view, the
> warnings are TRUE warnings about BAD programming practice,
> and stay forever.
The warnings should stay IMO. They aren't errors, but they are
important.
> > I like to now about unresolved data
> > references. I would really like to see how --auto-import works with
> > new C++ ABI before I am comfortable with that switch being on by
> > default.
>
>
> Well, now, that's something I hadn't considered. Good point.
> Warnings
> should probably stay, then. But that doesn't mean that auto-import
> shouldn't become the default.
For Danny - you can always build with --no-auto-import if you need the
original behaviour for some project. I think that auto-import should be
the default for cygwin, for now. It's too useful in the common case to
be disabled.
Rob
- Raw text -