John W. Eaton wrote:
> If I add "using gnulib::open;" inside the "#ifdef __cplusplus" block,
> ...
> then I don't even have to prefix all of the uses of open in my code
> with gnulib::. This seems like the best solution for me.
A good idea. Unfortunately I cannot see how to make it work: This pro
John W. Eaton wrote:
> Maybe I'm missing something, but what happens if @GNULIB_OPEN@ is 0?
> It doesn't look like we get the symbol inside the gnulib namespace in
> that case.
Yes. This is intentional. When @GNULIB_OPEN@ expands to 0, it means that
the programmer has not asked for the function 'o
Hi,
While looking through my Debian bug reports, I came across
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564181, and went to
check whether the corresponding updates had been applied to the PO file
held by the TP. The translator had indeed updated the PO file there as
I requested.
Unfortun
On 19-Feb-2010, I wrote:
| To handle all the cases, I find that I need to write
|
| #ifdef __cplusplus
| namespace gnulib
| {
| int (*const open) (const char *filename, int flags, ...) =
| # if @GNULIB_OPEN@
| # if @REPLACE_OPEN@
| ::rpl_open;
| # else
| ::open;
|
On 18-Feb-2010, Bruno Haible wrote:
| Ralf proposes:
| > I suggest you could
| > produce a helper header to #undef them again; you could even do that
| > automatically during bootstrap with above. Then only a portability
| > layer would need to avoid using these symbols in another namespace.
|
|
Bruno Haible wrote:
> Bruce Korb wrote:
>>> ${glib} --import ${gnulib_libs}
>>>
>>> ( echo
>>> echo '## begin sharutils stuff'
>>> echo
>>> echo "EXTRA_DIST += ${extra_libs}"
>>> ) >> lib/Makefile.am
>> yielding this as the end of lib/Makefile.am:
>>
>>> ## begin sharutils stuff
>>>
>>> EXTRA
Bruce Korb wrote:
> > ${glib} --import ${gnulib_libs}
> >
> > ( echo
> > echo '## begin sharutils stuff'
> > echo
> > echo "EXTRA_DIST += ${extra_libs}"
> > ) >> lib/Makefile.am
>
> yielding this as the end of lib/Makefile.am:
>
> > ## begin sharutils stuff
> >
> > EXTRA_DIST += \
> >
Bruce Korb wrote:
> ... doesn't get installed by gnulib. It seems like
> md5.[ch] ought to be, but I can't determine which module they belong
> to.
It's the second time that someone reports difficulties in locating a module,
given the file name.
I'm adding a gnulib-tool option --find, and a docu
