unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Jan Nieuwenhuizen <janneke-list@xs4all.nl>
To: Andy Wingo <wingo@pobox.com>
Cc: "Ludovic Courtès" <ludo@gnu.org>, guile-devel@gnu.org
Subject: Re: cross building 1.9.14 for mingw
Date: Thu, 24 Feb 2011 10:39:38 +0100	[thread overview]
Message-ID: <1298540378.4306.71.camel@vuurvlieg> (raw)
In-Reply-To: <m3zkpowjqw.fsf@unquote.localdomain>

Andy Wingo schreef op di 22-02-2011 om 09:34 [+0100]:

Hi Andy,

> Excuse the long quote here

No problem.

> > I did, and Bruno Haible does not really care about this brokenness
> > or about cross compiling;
> 
> That is a totally unfair characterization, Jan.  You met him in the
> Hague and he did not seem particularly evil then :)

Why, of course not.  Good point!

As anyone with some basic understanding of the human psyche can  
testify: any characterization that you make of someone or something 
says next to nothing about the subject, but -- if you catch yourself
doing it -- may tell you a whole lot about yourself.  Thanks for
catching me, I apologise for my behaviour and will have a good look
into the evil in me.

> Have you noticed that Guile has similar flags?

Yes, lots of packages have these; it's just that I always thought these
flags were for broken compilers or esoteric setups.  There are over 250
packages in GUB's cross build system, and until now, it has not been
necessary to specify --with-libFOO=$DESTDIR/usr/lib for any of those.

> To be honest I don't find it too onerous to have to set these flags when
> compiling with DESTDIR.  Sure, it would be nicer if it were just one
> flag, and perhaps we can fix that; but as you have perhaps seen in the
> numerous discussions on bug-guile recently, it seems that
> AC_LIB_HAVE_LINKFLAGS solves real problems.

I'm glad to hear that, at least it means that my cross build troubles
were for a good cause...  So now I need to look into the problems
that AC_LIB_HAVE_LINKFLAGS actually solves and see how to keep solving
them while not breaking zero-config DESTDIR-builds.

> People who cross-compile are a hardy breed, and less numerous than
> normal folk.  If the outcome here is that you have to pass more
> configure flags, but I have to deal with less mail on bug-guile, thus
> actually letting me hack again (!), I will take AC_LIB_HAVE_LINKFLAGS
> any day ;)

Haha!  Let me see if I understand you correctly: You are happy to get
less bug reports, which means more time to hack, even if it means that
cross build systems (such as mine) get more fragile and cross builders
will have to spend some of the time that you win, to maintain them?

Actually, this fits my idea that upstream time is most precious.  The
irony here, is that Han-Wen and I created GUB to give us more time
to hack: distribute turn-key binaries for everyone, so that we don't
have to deal with bug-reports of users trying to build from source.

To be serious, I had the dubious thought that what AC_LIB_HAVE_LINKFLAGS
was fixing by looking in /usr, must essentially be broken setups.
If that's the case, I would much rather see we find a way to fix
or prevent such broken setups, rather than trying to be smarter than
gcc and break well-behaved -- even if rarely used -- DESTDIR setups.

I realise that DESTDIR setups were not broken per se, but it was
considered a good trade-off to induce a maintenance burden to cross
builders because it would help users and upstream.

> I appreciate the work that you are doing on MinGW.  It will be nice for
> the oppressed denizens of Microsoft to have Guile relief.  So, ánimo,
> peregrino: we'll get there yet.

Thanks and yes, that's a helpful attitude.  Almost there...

Greetings, Jan

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  




  reply	other threads:[~2011-02-24  9:39 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-29 19:41 cross building 1.9.14 for mingw Jan Nieuwenhuizen
2011-01-29 21:34 ` Ludovic Courtès
2011-01-31 20:16   ` Jan Nieuwenhuizen
2011-01-31 20:44     ` Ludovic Courtès
2011-02-15 10:20   ` Jan Nieuwenhuizen
2011-02-22  8:34     ` Andy Wingo
2011-02-24  9:39       ` Jan Nieuwenhuizen [this message]
2011-02-24 10:37         ` Ludovic Courtès
2011-03-04 11:11         ` problems solved by AC_LIB_HAVE_LINKFLAGS [was: cross building 1.9.14 for mingw] Andy Wingo
2011-03-20  8:08           ` Jan Nieuwenhuizen
2011-03-20  8:21             ` Ralf Wildenhues
2011-03-20  8:34               ` Jan Nieuwenhuizen
2011-03-20  8:56                 ` Ralf Wildenhues
2011-01-29 21:39 ` Relocatable installation Ludovic Courtès
2011-01-31 20:26   ` Jan Nieuwenhuizen
2011-01-31 20:50     ` Andy Wingo
2011-01-31 20:55       ` Jan Nieuwenhuizen
2011-01-31 21:30         ` Andy Wingo
2011-01-31 21:49           ` Jan Nieuwenhuizen
2011-01-31 21:00     ` Ludovic Courtès
2011-01-31 21:18       ` Jan Nieuwenhuizen
2011-01-31 22:09         ` Ludovic Courtès
2011-01-31 22:26           ` Jan Nieuwenhuizen
2011-02-14 12:29 ` cross building 1.9.14 for mingw Ludovic Courtès
2011-02-15 10:02   ` Jan Nieuwenhuizen

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=1298540378.4306.71.camel@vuurvlieg \
    --to=janneke-list@xs4all.nl \
    --cc=guile-devel@gnu.org \
    --cc=ludo@gnu.org \
    --cc=wingo@pobox.com \
    /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).