bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HAVE_STDBOOL_H, AC_HEADER_STDBOOL, and AM_STDBOOL_H


From: Ralf Corsepius
Subject: Re: HAVE_STDBOOL_H, AC_HEADER_STDBOOL, and AM_STDBOOL_H
Date: Tue, 01 Feb 2011 15:13:37 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7

On 02/01/2011 02:29 PM, Simon Josefsson wrote:
Ralf Corsepius<address@hidden>  writes:

Please don't make this last change in Autoconf.  AC_HEADER_STDBOOL in
Autoconf works well right now for people who do not use gnulib,
Agreed. I am one of these users.

and I
don't think that it's a good idea to mark obsolescent a working Autoconf
macro to try to "push" people towards using gnulib instead.
Agreed, again.

For real-world projects, gnulib often is not a viable alternative.
Could you explain why?  There are several real-world projects that use
gnulib, so I'm curious what the perceived reasons against it are.  I'm
genuinely interested in the answer to the question, it is not just
rethoric because I happen to disagree.

I can understand if you are building non-free software you would not
want to use gnulib due to license reasons, but you could still use
autoconf.
Somewhat oversimplified, this applies to us.

RTEMS is an OS for embedded systems and is licensed under a "GPL with exceptions for static linkage". We choose to do so, because to users RTEMS presents itself as a set of static libraries, they statically link their application code against.

As we do not want to force our users to release their code, "pure GPL'ed" code is not applicable to us.

   However, I'm not sure this is the problem you are thinking of
or if there is some technical or other reason.
Yes, there also are technical reasons.

In first place, like most free OSes, we are in the unique position to have fairly wide control over the OS, its libc and its toolchains (gcc/binutils). I.e. we can try t fix issues once they pop up and don't necessarily have to resort to "portability aids" such as gnulib.

Another technical aspect would be integration of gnulib into existing source trees.


And finally, there are personal preferences and likes/dislikes. Some people consider gnulib to be great, others don't.

Except that i don't like the auto*tool's tendency to link the auto* and gnulib (such as in this thread) my personal position on gnulib is neutral.

Ralf





reply via email to

[Prev in Thread] Current Thread [Next in Thread]