On Fri, Jul 11, 2008 at 10:43 AM, <[EMAIL PROTECTED]> wrote:
> Fully I agree. After the successful execution of configure script,
> I found many cpp techniques in FreeType2 didn't work correctly in
> bcc's cpp. Oops. Although my interest was not ELKS + bcc itself,
> I will have to search the curre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Ralf Wildenhues on 7/8/2008 2:57 PM:
| This is odd. I can confirm it though: bcc ("Bruce’s C compiler")
| doesn't throw a compile error for
|
| static int test_array [1 - 2 * !(((long int) (sizeof (int))) <= 1)];
| test_array[0] = 0;
|
Hi,
I have this library, it includes autoconf generated config.h in its public
headers. Now, config.h defines PACKAGE_* set of symbols. The problem is that
if user programme or another library also uses autoconf and config.h, the
PACKAGE_* (and also other) symbols are now being #defined twice,
Hello Václav,
* Václav Haisman wrote on Wed, Aug 06, 2008 at 09:19:41PM CEST:
> I have this library, it includes autoconf generated config.h in its
> public headers.
The right approach is to never install config.h, and never let installed
headers include it. If you must, then have a second conf
* Eric Blake wrote on Wed, Aug 06, 2008 at 03:19:51PM CEST:
> According to Ralf Wildenhues on 7/8/2008 2:57 PM:
> | This is odd. I can confirm it though: bcc ("Bruce’s C compiler")
> | doesn't throw a compile error for
> | so I'm wondering whether we should change the test. Changing
> | AC_LANG_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've written a treatise on this subject in my autotools book:
http://www.freesoftwaremagazine.com/books/agaal/catalog_of_reusable_solutions
The first sub-topic is the one you want - "Never expose config.h in a
public interface".
- --john
Ralf Wilde
