unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Kevin Ryde <user42@zip.com.au>
To: guile-devel@gnu.org
Subject: Re: Gnulib support
Date: Thu, 06 Sep 2007 10:22:56 +1000	[thread overview]
Message-ID: <87myw0lk0v.fsf@zip.com.au> (raw)
In-Reply-To: <87veaqj30y.fsf@laas.fr> ("Ludovic Courtès"'s message of "Tue, 04 Sep 2007 09:36:13 +0200")

ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>
> Please, do read the thread on `bug-gnulib'.

I did.

> Widespread libraries already fixed the problem,

No.

> the most straightforward solution being to
> use Libtool's `-export-symbols-regex' link option (which is a single
> line in `Makefile.am').

Alas doesn't help the static ".a".  You'll also notice in the libtool
manual the caution "no effect on some platforms".

> Did you actually hit a problem?

Neither you nor I will hit a problem.  The systems hurt are ones noone
here hardly ever has to use, which is why it's essential to be very
careful about supposed "help".

It's a great shame really the gnulib bits are being done as yet more
code plonked into every package, to be updated in every package for
every new non-standard system, etc.  The quantity of autoconf, automake,
libtool, gettext, etc already dedicated to egregiously non-free systems
is pretty sad.  If only someone would "bit the bullet" and make a gnulib
or gnuification scheme that brought all those systems (those anyone
cares enough about) up to a gnu level in one hit. :(

> And while we're at it, I suggest that we do "mv libguile/*.[ch] .".
> Subdirs like that are unnecessary, too.  :-)

Don't move stuff about for no reason.  I've asked you before please not
to do things like that just because you feel like it.  It's not year
zero, and there's not enough manpower for actual fixes let alone notice
unintendend consequences of supposed cosmetic changes.  Hiding the build
tools in a subdir is pointless, its only effect is to obscure the
machinery, invalidate a paragraph in the INSTALL file, and give a nice
chance of breaking bits in the tree that assume things are where they
always have been.

> Hmm, I did not move the licence in `NEWS', though I did remove a few
> lines from there [0].  Is this what you are referring to?

The "dist-hook" rule is the best place to make dist-time consistency
checks.  A grep there can do what "check-news" does, but without having
to mangle the file, and indeed with a tighter regexp pattern to suit the
actual format used.  Assuming this is something really wanted at all --
since it should be clear dist restrictions must be made sparingly or
they're just pains in the proverbial.

The sole dist check I've found any good has been looking for "fuzzy"s in
po files, since gettext frequently makes extremely poor guesses at new
message translations.  On the other hand an example of a check that's
too agressive for a dist restriction is demanding all files modified
this year should have this year in the copyright line.  Worth grepping
from time to time, but too easy to get a false miss.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


  reply	other threads:[~2007-09-06  0:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-29 15:38 Gnulib support Ludovic Courtès
2007-08-16  0:23 ` Kevin Ryde
2007-08-20  8:07   ` Ludovic Courtès
2007-08-20 23:59     ` Kevin Ryde
2007-08-21  7:53       ` Ludovic Courtès
2007-08-25  8:44       ` Ludovic Courtès
2007-09-04  0:27         ` Kevin Ryde
2007-09-04  7:36           ` Ludovic Courtès
2007-09-06  0:22             ` Kevin Ryde [this message]
2007-09-10 11:40               ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87myw0lk0v.fsf@zip.com.au \
    --to=user42@zip.com.au \
    --cc=guile-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).