You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2004/04/01 19:42:53 UTC

Re: Plurals in translations was Re: [STRAW POLL] Help on i18n translations?

On Thu, 2004-04-01 at 14:21, Nicolás Lichtmaier wrote:
> System headers react to some macros by changing what is defined (e.g. 
> _GNU_SOURCE), and some autoconf macros depend on this.

This would be a valid argument, but since we rely on APR for most
portability concerns, we're unlikely to use any such autoconf macros.

> Besides, config.h might suply for missing features in the current
> compiler (bool, const, inline, etc.) and those things should also be
> defined when parsing the headers.

Absolutely not.  Our public headers cannot rely on stuff from config.h,
because config.h is not installed.  (If it were installed and used, it
would stomp all over the calling application's namespace.)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org


Re: Plurals in translations was Re: [STRAW POLL] Help on i18n translations?

Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2004-04-01 at 14:46, Nicolás Lichtmaier wrote:
> What some libraries do is to ship config.h under a new name (the current 
> subversion name for this file would be perfect for that).

Any library that does so is severely broken.  It's not even a little bit
okay to #include <svn_pools.h> and get things like HAVE_MEMORY_H
defined.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org


Re: Plurals in translations was Re: [STRAW POLL] Help on i18n translations?

Posted by Nicolás Lichtmaier <ni...@reloco.com.ar>.
>>Besides, config.h might suply for missing features in the current
>>compiler (bool, const, inline, etc.) and those things should also be
>>defined when parsing the headers.
>>    
>>
>
>Absolutely not.  Our public headers cannot rely on stuff from config.h,
>because config.h is not installed.  (If it were installed and used, it
>would stomp all over the calling application's namespace.)
>  
>

What some libraries do is to ship config.h under a new name (the current 
subversion name for this file would be perfect for that).


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org