This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [crosstool-NG] Design discussion


On Monday 06 April 2009 00:45:30 Rob Landley wrote:
> A) Your definition of "done" does not involve having actually configured or 
> built a toolchain yet.  This "done" is equivalent to "I just extracted the 
> tarball" in any other project.

Which about to be true! ;-)

> B) What other project has both ./configure and menuconfig?  Generally, you 
> have one or the other, not both.

Except they do not serve the same purpose!

- ./configure is to configure the crosstool-NG "program"

- "menuconfig" is the same as if you fired vi and edited some variables.
  Except that it tries to provide a more user-friendly interface.

> C) I didn't check out out of svn.  (I don't want to start out with a random 
> svn snapshot, because I have a knack for picking broken ones.  I want to 
> first try a release version with known bugs, that presumably worked for 
> somebody at some point.)

Agreed. Now, the 1.3 series is now 4-month old, and the trunk has add quite
a number of enhancements, although not the ones _you_ would expect.

> E) Why isn't that the default?  (Why even _have_ --local be an option?)

Well, I meant it to be installable for a two main reasons:

- share the same crosstool-NG so that users on the same system can build
  different toolchains for different (or identical) platforms, depending
  on their needs. We have a build machine at work, where users log in to
  build their software, and some have the right (project-wise) to build
  their own toolchains (notably when a new platforms arrives).

- make it packageable by any distribution (I know that it;s been in the
  OpenSUSE factory for a while now, even if it's not in the main distro)
  I'm planning to make a Debian package (in fact two: one with the core,
  named smthg like ct-ng-[version]-noarch.deb, and one with the patchsets,
  named ct-ng-data-[version]-noarch.deb)

> F) Running ./configure with no arguments died because awk doesn't call itself 
> gawk, and that's where I punted until I felt more awake.  The "fight with 
> getting it installed again" was:
> 
>   1) Run ./configure, watch it die, install gawk.
>   2) Run ./configure, watch it die, install bison.
>   3) Run ./configure, watch it die, install flex.
>   4) Run ./configure, watch it die, try to install makeinfo, realize that 
> ubuntu hasn't got a package called makeinfo, install its suggestion 
> of "texi2html", find out that ./configure still claims it hasn't got 
> makeinfo, do "aptitude search makeinfo" and come up with nothing, think for a 
> bit remember that ubuntu has a fiddly thing its shell does when you mistype a 
> command to suggest some random package you could install that will give you 
> an "sl" command, type makeinfo at the command line, have it suggest texinfo, 
> install texinfo.
>   5) Run ./configure, watch it die, install automake.
>   6) Run ./configure, watch it die, install libtool.

So you're suggesting that I continue with the checks, marking all missing
tools, reporting those at the end, and then aborting. Right?

No ./configure I know of behaves like this. So I was quite dumb, and followed
the herd. Thanks to you, a few steps further, I had fallen over the bridge...

> And _then_ it tells me it wants to install in /usr/local, which I can work 
> around with --prefix=`pwd` or its synonym --local,

*NOOOO!!!*** --prefix=`pwd` is *not* the same as --local! Argghh...

> except I did `pwd`/subdir 
> because I wanted to see what it was actually installing.

> The first thing I'd like to say about the prerequisite packages in step F is 
> that on this laptop I've already built my Firmware Linux system for armv4l, 
> armv5l, armv4eb, mips, mipsel, powerpc, powerpc-440, x86, x86-64, sparc, sh4, 
> m68k, and a couple of hardware variants like the wrt610n and User Mode Linux.  
> I didn't need _any_ of those packages to build binutils, gcc (with g++), 
> uClibc, uClibc++, busybox, make, bash, distcc, and the linux kernel.
> 
> You should never need the name "gawk", the SUSv4 name is awk:
>   http://www.opengroup.org/onlinepubs/9699919799/utilities/awk.html
> 
> And gawk installs such a symlink.  The FSF ./configures will detect "awk" and 
> use it.  The version Ubuntu installs by default is just "awk", the version 
> busybox provides is also "awk", and they work fine.

No, they don't for me. I'm using GNU extensions. I know its bad. They are
going away...

> The FSF packages ship with cached lex and yacc output, same for autoconf.  It 
> won't regenerate those if the host packages are there, but use the cached 
> versions.  The Linux kernel also has _shipped files for the few things that 
> involved yacc (mainly the menuconfig stuff), and I believe that actually 
> won't regenerate those unless told to do so manually.

Ah, but there is a bug in either Gentoo *or* one of the MPFR tarballs. It
works great on me Debian. I have had reports it was successful on Fedora.
I have seen it work seamlessly on OpenSUSE. It broke under Gentoo:
    http://sourceware.org/ml/crossgcc/2008-05/msg00080.html
    http://sourceware.org/ml/crossgcc/2008-06/msg00005.html

> The "info" documentation format is obsolete.  It was the FSF's attempt to 
> replace man pages 20 years ago, and it utterly failed.  There was zero uptake 
> outside the FSF, partly because their interface was based on "gopher" which 
> lost out to the web circa 1993.

I don't care. Some components will not build without it, they want to
update their documentation, and I can't spend time on fixing those
suckers. So requiring makeinfo is easier than trying to do without it.

> (Actual software is secondary to that lot, their 
> political/religious crusade is what they really care about.)

Please, Rob. Please...

> To make a long story short (too late!), everything that uses makeinfo uses 
> autoconf, and will skip it if it isn't there.

Not true in practice.

> I mentioned libtool last time.

I already answered to that one.

> One way to make cross compiling easier is 
> to _uninstall_ things like libtool so they can't screw stuff up.

But I can't demand to the end user that he/she removes packages on his machine
that might be usefull to him/her!

Well, you could reverse the argument by saying I can't impose him/her to
install stuff they don't need. But in that case they won't be able to use
crosstool-NG. Unless they come up with a change-request and a proper patch.

After all, if you want to compile some software, you'll need a compiler.
And if you don't want to install that, then you won't be able to compile
your software.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'


--
For unsubscribe information see http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]