Storing toolchain configurations and toolchains inside the crosstool-ng tree

[patrickdepinguin <patrickdepinguin at gmail dot com>]

Hi Yann, all,

Now that crosstool-ng is deprecated inside buildroot, I'm
transitioning to standalone crosstool-ng for building toolchains.
In buildroot, I had two defconfigs for a given project, one for
building the crosstool-ng toolchain, and one for the real project. The
toolchain defconfig would refer to a crosstool-ng config file. After
building, I would create a tarball of the contents of output/host/usr.
This tarball would then be used as an external toolchain in the second
defconfig file.
The defconfig files were stored in the buildroot configs/
subdirectory, while the crosstool-ng configs were stored inside
board/<manufacturer>/<project>.

All this is done in a version-controlled buildroot repository. A user
wanting to reproduce the toolchain simply does 'make foo_defconfig'
followed by 'make'. I'm looking for a similar simplicity in the new
approach.

I have now set up a clone of crosstool-ng. In it, I would first run
'make --enable-local', instead of 'make --prefix=/foo' because I want
to avoid extra locations outside the repository. In fact, all paths
involved in the creation of the toolchain are temporary, as the
toolchain will still be tarballed and used as an external toolchain
for buildroot later on.
After setting up crosstool-ng with --enable-local, I need to set a
configuration. At first sight, using the existing 'samples' directory
to store my project-specific configurations is most convenient. After
all, there already are provisions to store such configurations using
'ct-ng saveconfig', and to set an existing configuration. However, I
faced three issues with this:

1. the samples are named after the tuple. This means that if I make a
project-specific toolchain that happens to have the same tuple as an
existing sample, saving it would overwrite the existing sample.
Because I want to make sure I can easily upgrade to newer versions of
crosstool-ng without too much merging, I want to avoid overwriting
existing samples.
One solution I could think of is to use a custom vendor string, so
that the tuple is unique for my project. This certainly works, but if
there are other solutions I'd be glad to hear about them.

2. As I want to keep the toolchain installation inside the
crosstool-ng repository, because it will be removed after tarballing,
I had set CT_PREFIX_DIR to ${CT_TOP_DIR}/foo/${CT_TARGET}. (more about
'foo' later). Unfortunately, the saveconfig command filters out
CT_PREFIX_DIR from the saved configuration file. Hence, when
re-setting this configuration, the toolchain ends up in the default
${HOME}/x-tools/${CT_TARGET}.
The only way I see to fix this, is to make a modification to
crosstool-ng, either to stop filtering out CT_PREFIX_DIR from the
saved config (although I understand that it may not be ok for other
use cases), or providing another way to easily save and set a
configuration.
I have thought of the using 'ct-ng savedefconfig' and storing the
configuration elsewhere inside the tree, but this seems a bit
duplication of the 'samples'.

3. Regarding the location 'foo' where the toolchain can be temporarily
saved inside the tree: at first I put the toolchain in a subdirectory
output/, in analogy of what buildroot does. Unfortunately, there is no
existing way of cleaning that directory. Neither 'ct-ng clean' nor
'ct-ng distclean' cleans the installed toolchain, and didn't
immediately find a way to do this using ct-ng (unless of course
manually removing the directory with rm).
Then I saw that distclean does remove the legacy location 'targets',
so I figured I could use this directory for storing the toolchains.
It's a bit of a hack, though, and when you remove this legacy code,
I'll have a problem again.
Therefore, I'd like to know if we can come up with another way to meet
my need. One possibility is to add a new command to remove the
generated toolchain(s), another is to foresee a specific directory
where users can put their toolchains if they want to and have this be
removed with distclean. There surely are other solutions as well.

Looking forward to your thoughts...

Thomas

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