Ken Raeburn wrote:
On May 14, 2005, at 08:40, 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?
If the application refers to Guile functions without including
libguile.h, yes.
Or if an older version of gcc is used that can generate ELF sections
but doesn't support the "deprecated" attribute. (I *think* "section"
came first.)
Or if we add support for another compiler that lets us use 'asm' to
emit warning sections or symbols or whatever the tool chain supports,
but doesn't have a compile-time equivalent to the "deprecated"
attribute, but we could treat that case separately.
Or...
All of which strike me as pretty marginal.
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.
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.)
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.
scm_c_issue_deprecation_warning (though I don't know if I need to
worry about i18n interactions there).
I don't believe it's yet been suggested that we would translate the
Scheme names of primitives, so I doubt there would be a problem here.
(Out of interest, do any other scripting languages do this?)
I was thinking of the "is deprecated, please use" part. The symbol
names we should display as they are, but possibly the recommendation to
change the application code should be given in Swahili or Klingon or
whatever. That we could do at run time, and gcc could do it at compile
time, but I don't think we can do anything about it at link time.
I see - thanks for explaining.
Regards,
Neil
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
