On May 26, 2005, at 14:58, Neil Jerram wrote:
What is the extra benefit of link-time warnings over compile-time?
Are there any cases where the user will see a link-time warning
without a corresponding compile-time one?
[...]
All of which strike me as pretty marginal.
Okay...
Would link-time warnings show up when linking against a 3rd party
library that chose to use deprecated symbols?
Yes. Hmm, at least for a static library. I'm not sure about a
shared library, if it would happen when the library was built, or
used, or both. I would assume they would be printed when the library
is built, at least. I'm guessing that this would probably be the
most interesting of the cases.
Interesting in a sense, yes - but I was thinking that this is a good
argument for NOT implementing link-time warnings. The point being
that in this case the developer can't do anything about the warnings,
so they're just an annoyance.
Good point.
If these were security-related warnings, I'd suggest that they should
be displayed anyways, to make the end user/developer aware that they're
using software that could potentially compromise their systems. But
for deprecated symbols, all one could do would be to complain at the
third party supplying the library.
Or, in the real world, if all the non-fatal compile-time warnings
have all scrolled off the screen and the trailing bits of the "make"
output still visible, and the only bits likely to get looked at
unless something breaks, include only the final link step.
Seriously? (In my real world, if people are concerned about warnings
they put processes in place so as not to miss them.)
Well, I haven't looked over people's shoulders much while they build
software, but enough software has warnings while building that I expect
that's not the normal process for a lot of people. But if an
"interesting" warning (i.e., not the
pointer-assignment-changes-signedness or cast-changes-alignment or
other relatively benign warnings they may be in the habit of ignoring)
is still on-screen when the build finishes, maybe they'll take note.
Also, in some packages, link time is when arbitrary developer-provided
warnings get displayed now, if only because compile-time support hasn't
been there.
Hmm... come to think of it, though, we're increasingly working in a
world where building software package X requires that you have software
package Y installed, and software package Y may be built via some
provided package system that routinely ignores warnings as it builds
and installs some large collection of packages based on some dependency
tree. That might be a case where someone hacking on package X might
like to know that package Y does have some issues, and they might be
able to do something about it, but they wouldn't normally go looking
for problems there.
If it's not that interesting after all, I could drop it (as I
indicated, it's the more complicated approach, though not terribly
so) and just go with the compile-time warnings based on the
predefined macros.
That would be my inclination.
Okay. Unless someone else wants the link-time warnings, I'll start
backing that part out of my source tree soon. They're pretty
independent, so it wouldn't be hard to put them back in later as a
separate bit of work.
Ken
P.S. Apparently I've got updated assignment forms I need to file --
the FSF has already sent them to me -- and I probably need to get the
current disclaimer form to my current employer. So it'll take a little
while yet before the patches can go in. But I'll try and send
something for review soon anyways.
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
