Storing toolchain configurations and toolchains inside the crosstool-ng tree

Yann E. MORIN yann.morin.1998@free.fr
Thu Jul 25 17:58:00 GMT 2013


Thomas, All,

On 2013-07-25 19:33 +0200, patrickdepinguin spake thusly:
[--SNIP--]
> 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.

I think the custom vendor string is the correct way to differentiate two
otherwise identical toolchains. After all, that its only reason to exist
in the first place! ;-)

Otherwise, what about:
    ct-ng savedefconfig DEFCONFIG=samples/my-project/my-beloved-toolchain
    ct-ng defconfig DEFCONFIG=samples/my-project/my-beloved-toolchain

You do not even have to name the toolchains with a tuple this way (but
arguably, if you want to use the tupple, it is a bit more comples this
way.)

(Note: the DEFCONFIG variable name was recently changed in the
repository; previously, it was called CONFIG, but the doc and the code
did not agree on the naming, so the doc won, and the code now uses
DECONFIG.)

> 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}.

This is expected, so that when I do saveconfig, the sample does not
include my local path. This way, when a user recalls a sample, we are
sure the install dir will be in a writeable location. And the only
location we are sure is writeable by the user is in a sub-dir of his
${HOME}.

> 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),

Not possible, as explained above.

> 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'.

See above, that's what I do suggest.

> 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.

Care to send a patch to change the comment from "remove legacy build
dir" to "remove legacy build-dir *and* localy installed toolchains" ?
Plus a nit in the doc about this new feature, of course. ;-)

That way, we treat targets/ as the legacy build-dir, *and* the new
locally-installed toolchains at the same time, and the code won't be
removed in the future.

Note: I'm not happy with the phrase "locally-installed". Feel free to
come up with a better wording.

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



More information about the crossgcc mailing list