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] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |