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

See crosstool-NG 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: Storing toolchain configurations and toolchains inside the crosstool-ng tree


Hi Yann,

On Thu, Jul 25, 2013 at 7:58 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> 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.)

Thanks for your feedback.
I'm gonna go for the savedefconfig/defconfig alternative, as it
immediately fixes the CT_PREFIX_DIR removal issue.
As you suggest, I'll put it in a subdirectory of samples.

One new minor issue with this: if the subdir does not yet exist, the
savedefconfig fails without clear warning:

GEN   savedefconfig
*** Error while saving defconfig to: samples/my-project/my-beloved-toolchain

make: *** [savedefconfig] Error 1


I'm not sure whether it's kconfig or crosstool-ng that should attempt
to create the directory, or whether it's at all necessary to fix this.
What do you think?


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

Ok, I will.
What about calling them 'in-tree-installed toolchains', or 'in-tree
toolchain installations'
I also don't have much better suggestions, I'm afraid...

Thanks,
Thomas

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