crosstool-NG aims at building toolchains. Toolchains are an essential component in a software development project. It will compile, assemble and link the code that is being developed. Some pieces of the toolchain will eventually end up in the resulting binary/ies: static libraries are but an example.
I would also like to see crosstool-ng in portage. I've attached an ebuild and a patch. I'm going to try to get upstream to accept a more portable configure.ac rather than his current build method.
Created attachment 216589 [details] ebuild for crosstool-ng
Created attachment 216591 [details, diff] patch to fix configure to work with econf The current configure file does not accept a lot of the options passed by econf, like --build= and --host=. This patch is a hack to make configure silently ignore those options.
Created attachment 216598 [details] Should not have had unpack ${A} in src_prepare() The obsoleted version of ebuild should not have had the unpack and failed. This one works, but the man page is being installed to the wrong location. I will work on it.
Created attachment 216599 [details] Should not have had unpack ${A} in src_prepare() Damn, uploaded the patch instead of the ebuild.
Created attachment 216682 [details, diff] patch to fix configure to work with econf After discussion upstream, this is a better way of making configure compatible with gnu auto-stuff and econf.
doing `cd $S` in any function other than src_unpack is redundant -- drop it i dont think you use the savedconfig eclass ? your src_configure and src_compile functions are redundant -- delete them does the build system not like trailing slashes on $D ? seems like a bug in the Makefile that should be fixed ignoring that, you shouldnt create local variables without declaring them local: local MY_D=... if you only want to delete a trailing char, using `sed` is overkill. you can do the same thing with: emake DESTDIR="${D%/}" ... i'd tweak the description: "cross-compiling" "toolchains"
The patch has been accepted upstream. I will drop the patch and rewrite the ebuild with your suggestions once the patch hits their tree. BTW1, I am aware of where the issue is in the Makefile. Its trying to determine if a path is absolute or not. It correctly gets /path/to/somewhere as absolute but incorrectly thinks /path/to/somewhere/ is not. I'll try to debug that and get it upstream too. BTW2, you do not need the savedconfig. I had it there because crosstool-ng uses a make menuconfig, but that's when the user builds the x-tools with it, not when crosstool-ng is itself built. I meant to remove it.
Created attachment 218869 [details] ebuild for release crosstool-ng-1.6.0 The patch to fix configure to work with econf was accepted upstream. Release 1.6.0 plays nicely with portage now.
the --mandir option is screwy. it's supposed to set the base mandir, not a section-specific mandir. so it should be --mandir=/usr/share/man and it's up to the package to tack on .../man1/ or .../man8/ or ... the package doesnt need eutils eclass anymore, and the EAPI isnt necessary
It is a screwy workaround. Without it, the package installs the man page to /usr/share/man/ct-ng.1.gz. The problem with their build system is that the configure file was written by hand and so breaks with autotool conventions at places. The previous patch addressed part of the problem. The mandir issue is still there. In retrospect, a better approach would be to patch the configure file again and get it to install in man1. I'll pursue this approach and talk to upstream.
docs are installed in two places: by make install: /usr/share/doc/ct-ng-1.6.0/CREDITS /usr/share/doc/ct-ng-1.6.0/overview.txt by dodoc: /usr/share/doc/crosstool-ng-1.6.0/CREDITS /usr/share/doc/crosstool-ng-1.6.0/README /usr/share/doc/crosstool-ng-1.6.0/TODO /usr/share/doc/crosstool-ng-1.6.0/known-issues.txt /usr/share/doc/crosstool-ng-1.6.0/overview.txt I tried to pass --docdir=/usr/share/doc/$P to econf but this gave me docs under /usr/share/doc/crosstool-ng-1.6.0/ct-ng-1.6.0/ instead of /usr/share/doc/crosstool-ng-1.6.0/ This issue comes from package naming: even if the package name is crosstool-ng (project, tarball...), everything into the package is referred as ct-ng: /usr/bin/ct-ng /usr/lib/ct-ng-1.6.0/ /usr/share/doc/ct-ng-1.6.0/
I'm addressing the above issues with crosstools-ng-1.6.1 which was just released: Re Comment #12: I agree that renaming is the better approach. The next ebuild will be named ct-ng-1.6.1.ebuild. This solves the doc problem and keeps everything consistently named .../ct-ng on the filesystem. Re Comments #10 + #11: I'm still not sure how to fix this in an elegant fashion. The configure script (which is handwritten) does its job in a consistent way, but it is different from how gnu autotools work. I can patch it, but this approach makes it harder to maintain between releases. I'm not sure what I can get accepted/fixed in this regard upstream.
Created attachment 223903 [details] Addresses Comment #12
Created attachment 224131 [details] failed emerge of ct-ng-1.6.1 Emerging ct-ng-1.6.1 fails for me. See attached build.log.
Comment on attachment 224131 [details] failed emerge of ct-ng-1.6.1 Eh, I just tried emerging again and it worked without problems. Earlier failed build must have been a problem on my side...
Created attachment 233617 [details] Version bump for 1.6.2 I haven't forgotten about this, I've just been lazy about uploading the ebuilds for the new releases.
Created attachment 233619 [details] Version bump to 1.7.0
Created attachment 234349 [details] Saner approach to non-standard build system Re Comments #10 + #11: There isn't an elegant fix to the build system's --mandir problem. I've make a patch to fix it and I'll try to get upstream to address the issue. I also added bash-completion.
Created attachment 234351 [details, diff] Patch used by ct-ng-1.7.0-r1.ebuild
Okay, I am aiming to commit this to the tree in a week or so. I will attach the initial ebuild/patch/metadata.xml if anyone wants review them before I commit. They are also on my overlay: http://git.overlays.gentoo.org/gitweb/?p=dev/blueness.git;a=summary @toolchain: notice I am not including <herd>toolchain</herd>. In the near future, I am planning to write a bash utility which installs/uninstalls the newly constructed toolchain somewhere on the filesystem and adds the appropriate env.d files so that it works with gcc-config as do other cross/native compilers. I'm not sure where on the filesystem would be best, either /usr/local/tuplet or /var/lib/ct-ng/tuplet. Ebuilds are not supposed to use /usr/local, but since the ebuild doesn't install the toolchain, only the toolchain builder, /usr/local does not seem inappropriate.
Created attachment 238333 [details] ebuild for the latest stable release This will go into sys-devel/ct-ng
Created attachment 238335 [details, diff] Patch to fix the man page path
Created attachment 238337 [details] Package metadata Setting myself as the maintainer and taking full responsibility.
feel free to commit that then ... the man page issue should really be taken upstream, but if you want to maintain it, it's your call now
In the tree.
Created attachment 238913 [details, diff] Patch to fix the man page path If this patch fixes the mandir issue for you, I'm ready to push it.
