On Thu, 2 Apr 2009, Bruno Haible wrote:
Reuben Thomas wrote:
It didn't occur to me to read the manual, as I hadn't figured out
how to build it. I looked in Makefile, but that didn't seem to do much.
This can be improved:
[add doc-building targets to Makefile]
That looks helpful; thanks.
--
On Wed, 1 Apr 2009, Alfred M. Szmidt wrote:
> What is it that made you expect to see "installation instructions"?
Most GNU packages have an INSTALL file. That's where I look first for
installation instructions.
gnulib is not something you install. Ever.
I guess we mean different thing
Reuben Thomas wrote:
> It didn't occur to me to read the manual, as I hadn't figured out
> how to build it. I looked in Makefile, but that didn't seem to do much.
This can be improved:
2009-04-01 Bruno Haible
* Makefile (info, html, dvi, pdf): New targets.
Reported by Reuben
> What is it that made you expect to see "installation instructions"?
Most GNU packages have an INSTALL file. That's where I look first for
installation instructions.
gnulib is not something you install. Ever.
Simon Josefsson wrote:
> The current gethostname module will return an empty string on mingw:
>
> strcpy (name, ""); /* Hardcode your system name if you want. */
>
> This is sub-optimal since Windows has a gethostname function in
> -lws2_32.
>
> The following patch should make gethos
On Thu, 2 Apr 2009, Bruno Haible wrote:
That's the common convention for when you receive a package in the form of a
tarball. For CVS or git checkouts, there is no such conventions.
Well, most packages that have INSTALL have it also in the VCS. And gnulib
doesn't seem to have any of the optio
Reuben Thomas wrote:
> Most GNU packages have an INSTALL file. That's where I look first for
> installation instructions.
That's the common convention for when you receive a package in the form of a
tarball. For CVS or git checkouts, there is no such conventions. Some
packages have a README-alpha
On Thu, 2 Apr 2009, Bruno Haible wrote:
Reuben Thomas wrote:
because gnulib-tool is on PATH. That's all I want really, I want
gnulib-tool to be on my PATH and I was asking what I have to do to
make that work.
Ah, that was the real question behind the question!
Not really: that's
Reuben Thomas wrote:
> because gnulib-tool is on PATH. That's all I want really, I want
> gnulib-tool to be on my PATH and I was asking what I have to do to
> make that work.
Ah, that was the real question behind the question!
Karl Berry wrote:
> ln -s /gnulib/checkout/gnulib-tool ~/b
On Thu, 2 Apr 2009, Bruno Haible wrote:
What is it that made you expect to see "installation instructions"?
Most GNU packages have an INSTALL file. That's where I look first for
installation instructions.
--
http://rrt.sc3d.org/ | Aphorisms work only in retrospect
Reuben Thomas wrote:
> It would be nice to have a top-level INSTALL file that gives this
> information.
Are the two main sources of information, the public web page and the manual,
not enough? The web page [1] says:
"To use Gnulib, you can retrieve its source code ..."
and the manual [2], secti
On Wed, 1 Apr 2009, Karl Berry wrote:
I think the point is that you can install the gnulib Debian package
without an internet connection
That may be, but it doesn't make distributing a snapshot of gnulib as a
"package" any less problematic. It is still the wrong thing to do.
I don't se
I think the point is that you can install the gnulib Debian package
without an internet connection
That may be, but it doesn't make distributing a snapshot of gnulib as a
"package" any less problematic. It is still the wrong thing to do.
Oh well. I know this isn't up to you, and I certai
On Wed, 1 Apr 2009, Alfred M. Szmidt wrote:
> Any problem with adding gnulib to your path?
I prefer to add executable-only directories.
That makes little sense, if you wish to be able to access a directory,
then it must be executable.
Sorry, I was unclear. I meant directories containing
On Wed, 1 Apr 2009, Alfred M. Szmidt wrote:
You do not need a internet connection to compile a project that uses
gnulib, the project will include whatever parts of gnulib it uses.
I think the point is that you can install the gnulib Debian package without
an internet connection, just like any
> Any problem with adding gnulib to your path?
I prefer to add executable-only directories.
That makes little sense, if you wish to be able to access a directory,
then it must be executable.
>Well, Debian packages snapshots of it. It's useful,
>
> No, it is insanely wrong, defeating the purpose of gnulib and
> causing impossible-to-track bugs due to out-of-sync sources. But
> let's not go into that again, you can find the discussions in the
> archives if you care
On Wednesday 01 April 2009 15:32:36 Reuben Thomas wrote:
> On Wed, 1 Apr 2009, Mike Frysinger wrote:
> > the `git clone` is the install. just execute the gnulib-tool script from
> > there.
>
> Right. So I just add the directory to my PATH? Or symlink gnulib-tool into
> a directory on my PATH?
eit
On Wed, 1 Apr 2009, Alfred M. Szmidt wrote:
Any problem with adding gnulib to your path?
I prefer to add executable-only directories.
--
http://rrt.sc3d.org/ | RSA, n. safety in numbers
On Wed, 1 Apr 2009, Karl Berry wrote:
Well, Debian packages snapshots of it. It's useful,
No, it is insanely wrong, defeating the purpose of gnulib and causing
impossible-to-track bugs due to out-of-sync sources. But let's not go
into that again, you can find the discussions in the archives
> On Wednesday 01 of April 2009 21:32:36 Reuben Thomas wrote:
>> On Wed, 1 Apr 2009, Mike Frysinger wrote:
>>> the `git clone` is the install. just execute the gnulib-tool script from
>>> there.
>>
>> Right. So I just add the directory to my PATH? Or symlink gnulib-tool into
>
Simon Josefsson wrote:
> Ok, I have pushed the patch below.
>
> + Rename ld-version-script to lib-symbol-versions.
Thanks. I renamed likewise:
2009-04-01 Bruno Haible
Rename module 'visibility'.
* modules/lib-symbol-visibility: Renamed from modules/visibility.
*
Well, Debian packages snapshots of it. It's useful,
No, it is insanely wrong, defeating the purpose of gnulib and causing
impossible-to-track bugs due to out-of-sync sources. But let's not go
into that again, you can find the discussions in the archives if you care.
because gnulib-tool i
On Thu, 2 Apr 2009, Kamil Dudka wrote:
On Wednesday 01 of April 2009 21:32:36 Reuben Thomas wrote:
On Wed, 1 Apr 2009, Mike Frysinger wrote:
the `git clone` is the install. just execute the gnulib-tool script from
there.
Right. So I just add the directory to my PATH? Or symlink gnulib-tool
On Wednesday 01 of April 2009 21:32:36 Reuben Thomas wrote:
> On Wed, 1 Apr 2009, Mike Frysinger wrote:
> > the `git clone` is the install. just execute the gnulib-tool script from
> > there.
>
> Right. So I just add the directory to my PATH? Or symlink gnulib-tool into
> a directory on my PATH?
On Wed, 1 Apr 2009, Mike Frysinger wrote:
the `git clone` is the install. just execute the gnulib-tool script from
there.
Right. So I just add the directory to my PATH? Or symlink gnulib-tool into a
directory on my PATH?
It would be nice to have a top-level INSTALL file that gives this
in
Simon Josefsson wrote:
> Reuben Thomas writes:
...
>>> 4. Use of C_SOURCES in sc_* rules.
>>
>> There seems to be a conflict here between coreutils's approach (use a
>> list of exceptions generated from the VCS) and gnulib's (generate a
>> list of files to look at). What do you suggest as a next s
On Wed, 1 Apr 2009, Simon Josefsson wrote:
Coreutils doesn't use the gnulib maintainer-makefile module, I believe,
so at minimum it would need a patch that made it use maint.mk from
gnulib.
Or it could use maintainer-makefile, unless there's some reason why not?
Further, some of the rules in
* Simon Josefsson wrote on Wed, Apr 01, 2009 at 06:50:07AM CEST:
> Bruno Haible writes:
> > Your documented example looks like this:
> >
> >> +if HAVE_LD_OUTPUT_DEF
> >> +libfoo_la_LDFLAGS += -Wl,--output-def,libfoo-$(SOVERSION).def
> >> +defexecdir = $(bindir)
> >> +defexec_DATA = libfoo-$(SOVERS
Eric Blake writes:
> According to Simon Josefsson on 4/1/2009 9:30 AM:
>>> Even though Posix says this should silently return non-zero exit status,
>>> some test implementations complain to stderr if the argument starts with
>>> something that looks like an operator or option. Hence, any time yo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Simon Josefsson on 4/1/2009 9:30 AM:
>> Even though Posix says this should silently return non-zero exit status,
>> some test implementations complain to stderr if the argument starts with
>> something that looks like an operator or option
Eric Blake writes:
> According to Simon Josefsson on 4/1/2009 8:14 AM:
>> Thanks. Is there some way to systematically find these? A m4 code
>> validator or similar?
>
> Unfortunately, not that I know of. So the best we can do is repeatedly
> remind people to follow the autoconf rule of thumb:
Reuben Thomas writes:
> On Wed, 1 Apr 2009, Simon Josefsson wrote:
>
>> It will be easier to review if you post patches for gnulib's maint.mk
>> instead of the entire new file.
>
> I'll do that.
Thanks!
>> You may have to patch coreutils maint.mk too, but that could go to
>> bug-coreut...@gnu.o
On Wednesday 01 April 2009 11:17:25 Reuben Thomas wrote:
> I just decided to stop using Debian packages, which I have to download from
> sid in order to keep up to date in any case, and just do the obvious thing
> and get gnulib from git, which I can update whenever I like.
>
> However, I can't see
On Wed, 1 Apr 2009, Simon Josefsson wrote:
It will be easier to review if you post patches for gnulib's maint.mk
instead of the entire new file.
I'll do that.
You may have to patch coreutils maint.mk too, but that could go to
bug-coreut...@gnu.org.
I was hoping to end up with a single file
I just decided to stop using Debian packages, which I have to download from
sid in order to keep up to date in any case, and just do the obvious thing
and get gnulib from git, which I can update whenever I like.
However, I can't see any installation instructions. Am I missing something?
--
htt
I pushed the following since there weren't any objections to adding the
module. I believe the patch address most if not all comments so far.
Thanks for all the comments! Further review is still appreciated.
/Simon
>From 68f982e01be79f241a306e1dd7328fa1f307ab0c Mon Sep 17 00:00:00 2001
From: Sim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Simon Josefsson on 4/1/2009 8:14 AM:
> Thanks. Is there some way to systematically find these? A m4 code
> validator or similar?
Unfortunately, not that I know of. So the best we can do is repeatedly
remind people to follow the autocon
Eric Blake writes:
> According to Simon Josefsson on 4/1/2009 7:38 AM:
>> AM_CONDITIONAL(HAVE_LD_OUTPUT_DEF, test "$gl_cv_ld_output_def" = "yes")
>
> You still missed the m4 quoting.
Thanks. Is there some way to systematically find these? A m4 code
validator or similar?
> And now that the c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Simon Josefsson on 4/1/2009 7:38 AM:
> AM_CONDITIONAL(HAVE_LD_OUTPUT_DEF, test "$gl_cv_ld_output_def" = "yes")
You still missed the m4 quoting. And now that the cache can provide a
value, you should protect against a user that inserts
Reuben Thomas writes:
> On Wed, 1 Apr 2009, Simon Josefsson wrote:
>
>> Reuben Thomas writes:
>>>
>>> Since coreutils' maint.mk seems to be shared with other projects
>>> already, could it not simply be pushed into gnulib as it is? Could
>>> those projects (currently, according to the comments,
Eric Blake writes:
> According to Simon Josefsson on 3/31/2009 10:56 PM:
>> AC_MSG_RESULT($gl_output_def)
>> LDFLAGS="$gl_ldflags_save"
>> fi
>> AM_CONDITIONAL(HAVE_LD_OUTPUT_DEF, test "$gl_output_def" = "yes")
>
> Still missing m4 quoting. On the other hand, shell quotes around yes
On Wed, 1 Apr 2009, Simon Josefsson wrote:
Reuben Thomas writes:
Since coreutils' maint.mk seems to be shared with other projects
already, could it not simply be pushed into gnulib as it is? Could
those projects (currently, according to the comments, "coreutils,
idutils, CPPI, Bison, and Auto
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Simon Josefsson on 3/31/2009 10:56 PM:
> AC_MSG_RESULT($gl_output_def)
> LDFLAGS="$gl_ldflags_save"
> fi
> AM_CONDITIONAL(HAVE_LD_OUTPUT_DEF, test "$gl_output_def" = "yes")
Still missing m4 quoting. On the other hand, shell q
Bruno Haible writes:
>> One complication is that POSIX says the symbol should be defined in
>> limits.h. Do we need a gnulib replacement header for limits.h to be
>> able to define HOST_NAME_MAX?
>
> No, it is more convenient to define it in config.h, simply through
> AC_DEFINE.
...
> The defini
Simon Josefsson wrote:
> POSIX requires this symbol, but MinGW doesn't appear to define it:
>
> ../../../../src/gss-0.1.1/lib/krb5/name.c:89: error: 'HOST_NAME_MAX'
> undeclared (first use in this function)
>
> According to MSDN gethostname documentation:
>
> http://msdn.microsoft.com/en-us/lib
46 matches
Mail list logo
