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-t
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
On May 14, 2005, at 08:40, Neil Jerram wrote:
The warnings can be disabled while building guile (only while
building deprecated.c, I hope) so that -Werror doesn't kill the
build.
In the header files, here's how it's taking shape, roughly:
#if defined(SCM_DISABLE_DEPRECATION_WARNINGS)
# define SCM
On May 18, 2005, at 08:20, Ludovic Courtès wrote:
This sounds like a good idea. However, this would need to be somewhat
automated, like Debian's build system, still without compromising on
the
user's privacy and control. I think that's a project of its own, isn't
it? :-)
Definitely.
FWIW, I use
Hello,
Ken Raeburn <[EMAIL PROTECTED]> writes:
> Hmm... does anyone feel like setting up an array of test machines to
> automatically do frequent builds and tests of snapshots and report
> errors as they come up?
This sounds like a good idea. However, this would need to be somewhat
automated, l
On Mon, May 16, 2005 at 01:52:01AM -0400, Ken Raeburn wrote:
> On May 14, 2005, at 23:17, John W. Eaton wrote:
> [..."#define foo foo"...]
> >Can you point to a widely used compiler that will actually have
> >trouble with this? [...]
>
> Hmm... does anyone feel like setting up an array of test mac
On May 14, 2005, at 23:17, John W. Eaton wrote:
[..."#define foo foo"...]
Can you point to a widely used compiler that will actually have
trouble with this? If not, then maybe it is not worth worrying about?
Hmm... does anyone feel like setting up an array of test machines to
automatically do fre
John W. Eaton wrote:
On 14-May-2005, Ken Raeburn wrote:
| > I think we should assume in advance that we'll hit trouble with this
| > on some platforms. Otherwise it's just another hiccup to push people
| > away from trying Guile out.
|
| *sigh* I was afraid of that. So when do we start requir
On 14-May-2005, Ken Raeburn wrote:
| >> /* N.B.: Application code will sometimes test whether one of these
| >> macros is defined, to figure out if the version of Guile in use
| >> predates the creation of the macro. So at deprecation time, we
| >> still want the macro to be visible.
On May 14, 2005, at 08:40, Neil Jerram wrote:
This looks very useful. I'm not an expert in this kind of thing, but
here are some comments.
Thanks...
#elif defined _WIN32
Does the __declspec syntax work for all Windows compilers? If it's
actually specific to MSVC (which is the only compiler I'm
Ken Raeburn wrote:
Well, I've got a rough version up and limping, that does both
compile-time and link-time warnings:
This looks very useful. I'm not an expert in this kind of thing, but
here are some comments.
% make depr
gcc -I/var/raeburn/guile/guile-afs/Install/include -g -c -o depr.o
de
Some time back, I wrote:
It might be a bit annoying to do in the source, but what about
flagging deprecated symbols while still allowing their use, in the
non-"--disable-deprecated" case?
E.g., declare a function SCM_LENGTH, which is declared in the header
file with a macro which under recent e
12 matches
Mail list logo
