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