Building own versions of m4, autoconf, automake, libtool

Building own versions of m4, autoconf, automake, libtool

[Richard Strand]

Hi Yann, All,

I was looking at the to-do list in crosstool-ng and noticed the task for 
building own versions of m4, autoconf, automake, libtool. If this is 
still required I would like to write this functionality.

Did you imagine that once this was added crosstool would always build 
its own versions of these tools and use them, it only do it if the 
installed versions were old, or it would be configurable? I feel that 
building these tools should be fairly short and always building them 
would at lease ensure this code was tested - any thoughts?

Regards,

Richard Strand


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

Re: Building own versions of m4, autoconf, automake, libtool

[Yann E. MORIN]

Richard, All,

On Sunday 10 January 2010 19:10:13 Richard Strand wrote:
> I was looking at the to-do list in crosstool-ng and noticed the task for 
> building own versions of m4, autoconf, automake, libtool. If this is 
> still required I would like to write this functionality.

Thank you for looking at the TODO! :-)

This not /required/ per se. Building our own version would mean we get
less dependent on the host system. OTOH it gives us a good more maintenance
for something that is usually handled by the upstream distros.

You are welcome to tackle this, yes!

> Did you imagine that once this was added crosstool would always build 
> its own versions of these tools and use them, it only do it if the 
> installed versions were old, or it would be configurable? I feel that 
> building these tools should be fairly short and always building them 
> would at lease ensure this code was tested - any thoughts?

There are a few issues with building our own versions.

It adds maintenance costs to follow upstream, add and track patches,
fix build problems in some corner cases, and so on...

So far, crosstool-NG has only installed arch-independent files (either
shell scripts for the core of CT-NG, or source code for the mconf stuff).
This allows to export crosstool-NG install path to other machines that
can then all use the same version. I'd like to keep it.

We can't impose to the user to setup the PATH so that our versions appear
first, *and* we do not want the rest of the system to use our versions!

The default is to entice the user to either update his/her system, or build
necessary versions on his/her own.

So, the only place we can build those in when building the toolchain proper.
A bit like what we do for the companion libraries, let's add a sub-menu
"companion tools", a bit like:

Companion libraries  --->
Companion tools  --->
  [*] READ HELP before you say 'Y' here !!!
  [ ]   m4
  [ ]   autoconf
  [ ]   automake
  [ ]   libtool

Don't wait for a complete implementation before you submit, once you have
one of the tools added, post and we'll review the stuff before adding the
others.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  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