[CT-NG] Improve the installation process

Yann E. MORIN yann.morin.1998@anciens.enib.fr
Tue Aug 30 12:38:00 GMT 2011

Hello All!

I'd like to address two things in this email, both pertaining to
how crosstool-NG installs its internal files (not the toolchain).

1) kconfig frontends installation

Currently, crosstool-NG installs the kconfig stuff in source form, and
they get compiled afterwards. That is, every time you start working in
a new directory (eg. for a new toolchain), the kconfig stuff gets
compiled again.

In the beginings, the purpose was that a crosstool-NG installation could
be shared (eg. via NFS) for many machines, but even I no longer have this

2) generated config files installation

Also, some config files gets generated (eg. the architectures, C libraries,
and so on, menu lists). This means again that these files get regenerated
on every new toolchain, although obviously they did not change.

This is a reminiscence of the early days, when crosstool-NG was not
installable, and was kept as-is as I found it easier to test new config
knobs without re-running configure && make. Now I find it a little bit
dirty, and the build+install process is well established now.

I was wondering what you guys would think of the following:

- compile the kconfig frontends at ./configure+make, and install the
  built frontends with make install

- pre-generate the config files at ./configure+make, and install the
  pre-generated files with make install

So, crosstool-NG would behave yet a little bit more a traditional package,
where a change in the source files would require a re-build and a re-
install, or even restarting from ./configure

And for those who are hacking crosstool-NG, the process would not be much
more complex than it now is, using the --local switch to ./configure which
would still require no more than a mere make to apply the changes.

Of course, needless to say that I am really tempted to implement those
changes, so that crosstool-NG morphs yet a bit more into a real, normal
package that behaves the way people expects packages to behave.


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

More information about the crossgcc mailing list