On 05/03/2011 11:57 PM, Bruno Haible wrote:
Lorenzo Bettini asked:
Would it be correct to put config.h only say in file1.cpp (and use the
‘-I’ option that refers to the Gnulib library directory for that file
only), and not in file2.cpp and file3.cpp (where I don't use -I to refer
to g
On 05/03/2011 01:11 PM, Lorenzo Bettini wrote:
On 05/02/2011 02:59 PM, Bastien ROUCARIES wrote:
On Mon, May 2, 2011 at 12:02 PM, Lorenzo Bettini
wrote:
On 04/25/2011 06:36 PM, Bruno Haible wrote:
Lorenzo Bettini wrote:
on the manual I read
"These Gnulib substitute header files re
On 05/02/2011 02:59 PM, Bastien ROUCARIES wrote:
On Mon, May 2, 2011 at 12:02 PM, Lorenzo Bettini
wrote:
On 04/25/2011 06:36 PM, Bruno Haible wrote:
Lorenzo Bettini wrote:
on the manual I read
"These Gnulib substitute header files rely onbeing already
included. Furthermoremu
On 04/25/2011 06:36 PM, Bruno Haible wrote:
Lorenzo Bettini wrote:
on the manual I read
"These Gnulib substitute header files rely on being already
included. Furthermore must be the first include in every
compilation unit. This means that to all your source files and likely
also to all
ther by
also putting -lgnu?
or should I do something else?
thanks in advance
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http:/
ther by
also putting -lgnu?
or should I do something else?
thanks in advance
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
ther by
also putting -lgnu?
or should I do something else?
thanks in advance
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http:/
b version of getopt fixes
the problem right?
cheers
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
o
it looks kind of strange that getopt test fails under GNU Linux...
(indeed, this way, the gnulib version of getopt is used, instead of GNU
libc version)
cheers
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it MUSIC:
dditional #ifdef magic
would be required before the cast, e.g.:
#ifndef __getopt_argv_const
# define __getopt_argv_const const
#endif
Regards,
Sergey
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobetti
__argv
before invoking getopt_long?
many thanks in advance
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
Bruno Haible wrote:
Lorenzo Bettini wrote:
However, I then noticed that there's dirent as a module (and opendir is
declared in dirent.h) so I bet I should import dirent module anyway,
shouldn't I?
When you look at the gnulib/lib/dirent.in.h file, you see that it declares
only fun
Bruno Haible wrote:
Lorenzo Bettini wrote:
I saw that mkdir is a module in gnulib, while opendir (defined in
dirent.h) is not; thus opendir is assumed as standard?
Yes. You can see in the gnulib documentation [1] that no portability problems
are known for opendir().
This is because the only
Hi
I saw that mkdir is a module in gnulib, while opendir (defined in
dirent.h) is not; thus opendir is assumed as standard?
thanks in advance
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http
Eric Blake wrote:
> According to Lorenzo Bettini on 12/20/2006 12:44 PM:
>>> Thanks for the feedback. Last time we discussed whether gnulib-cache.m4
>>> should be added to EXTRA_DIST by gnulib-tool, so that anyone getting a
>>> tarball can do "gnulib-tool -
u already added
extern "C").
Probably it wouldn't be bad to always have extern "C" in all gnulib
headers since it would made them all usable in C++ programs too...
probably I'm biased though, since I prefer coding in C++ ;-)
however, this is also what the C/C++ lib
Eric Blake wrote:
> According to Lorenzo Bettini on 12/20/2006 12:44 PM:
>>> Thanks for the feedback. Last time we discussed whether gnulib-cache.m4
>>> should be added to EXTRA_DIST by gnulib-tool, so that anyone getting a
>>> tarball can do "gnulib-tool -
Bruno Haible wrote:
Lorenzo Bettini wrote:
You see, there's no clear borderline between <> and "".
I see, but are <> ensuring that the version of gnulib is used (even if
getopt.h is available in the system)?
The -I flags added by automake and gnulib-tool normal
Bruno Haible wrote:
Lorenzo Bettini wrote:
gnulib-tool says:
You may need to add #include directives for the following .h files.
#include
shouldn't it be
#include "getopt.h"
?
Given that the source and build directories are searched by the compiler
(due to the many &
Bruno Haible wrote:
Lorenzo Bettini wrote:
Maybe: "gnulib-tool --update" relies on the presence of gnulib-comp.m4 and
gnulib-cache.m4.
OK, those files were not there (this is because gnulib-cache.m4 is not
included in the .tar.gz produced by make dist, is this correct?)
no
Bruno Haible wrote:
Lorenzo Bettini wrote:
~/work/gnulib/gnulib-tool --update --dry-run
Module list with included dependencies:
File list:
lib/dummy.c
m4/onceonly_2_57.m4
Create directory ./lib
Create directory ./m4
Create directory ./lib
Create directory ./m4
Copy file lib/dummy.c
Copy
by the way, upon importing getopt, gnulib-tool says:
You may need to add #include directives for the following .h files.
#include
shouldn't it be
#include "getopt.h"
?
--
+---------+
| Lorenzo Bettini ICQ# l
Bruno Haible wrote:
Lorenzo Bettini wrote:
as reported in the documentation, I have the source base and m4 base,
resp., in gl and gl/m4
now I'm trying to run gnulib-tool --update as follows, but I get an error:
gnulib-tool --update --m4-base=gl/m4/ --source-base=gl/ --dry-run
gnulib
Yes, for the moment this is the only one.
In case I need some more I'll send you an email.
thanks a lot
cheers
Lorenzo
Bruno Haible wrote:
Lorenzo Bettini wrote:
I thus included a possible patch.
strdup.h is all you need? Ok, I commit
' mode
Try 'gnulib-tool --help' for more information.
If you really want to modify the gnulib configuration of your project,
you need to use 'gnulib --import' - at your own risk!
am I doing something wrong?
thanks in advance
Lorenzo
--
+-----
Bruno Haible wrote:
Lorenzo Bettini wrote:
I tried it and got no problem, but as far as I understand this is not a
proof, since
#if defined HAVE_DECL_STRDUP && !HAVE_DECL_STRDUP && !defined strdup
/* Duplicate S, returning an identical malloc'd string. */
extern char *
Bruno Haible wrote:
> Lorenzo Bettini wrote:
>> I've just started using gnulib, and I have a doubt.
>> I've imported strdup and I'm using it in a C++ program.
>>
>> Now should I import strdup.h in the C++ program simply like this
>>
>> #i
ude "strdup.h"
}
thanks in advance
Lorenzo
--
+---------+
| Lorenzo Bettini ICQ# lbetto, 16080134 |
| PhD in Computer Science, DSI, Univ. di Firenze |
| Florence - Italy(GNU/Linux User # 158233) |
| http://www.lore
28 matches
Mail list logo
