cvs ebuild: dev-lang/fpc Reproducible: Always Steps to Reproduce: 1. 2. 3.
Ok so here goes my started work for a fpc cvs ebuild. Took me hours to get it somewhat right. Too tired to finish. repeat: it is NOT finished (some unit directories and manpages and documentation missing) But posting it here so nobody has to go through that ordeal again, and to have a backup :)
Created attachment 49860 [details] the ebuild that works (beware, messy) ebuild that works
Created attachment 49861 [details] default fpc.cfg, to be put into "files" put this into files subdir of the ebuild dir
Created attachment 49862 [details] fpc main environment variable, to be put into "files" subdir put into "files" subdir of the ebuild dir
also missing is to somehow get the bootstrap compiler *not* to read /etc/fpc.cfg, /usr/lib/fpc/.... Because if it reads them, it could lead to that scenario: - bootstrap fpc compiles some fpc source in the sandbox - that source file uses a unit that is "old" (.o file older than .pp file or checksum wrong) from /usr/lib/fpc/... - thus that unit is automagically recompiled to - the unit's new .o / .ppu is tried to be stored into /usr/lib/fpc/... - sandbox kills emerge because of invalid write access
One might think that this ebuild could be done much simpler (I will attach an example for how here later), but this is not the case. It does compile+install just fine, however, the resulting compiler cannot be used to compile anything useful. Thus I use the following test: program testcontainer; uses contnrs; begin end. If that fails, you are victim to the installed-fine-but-broken-syndrome (i have been searching for the cause of that for 3 hours and gave up. its not funny)
Created attachment 49863 [details] ebuild: it could be so easy... or could it? It could be so easy... but nooo... this does _not_ work. Do not be fooled.
Created attachment 49864 [details] filelist diff what is to do to the final version A filelist diff from the installed files of 'ebuild with working compiler afterwards' to the installed files of 'ebuild with nonworking compiler afterwards'. Can be seen as a TODO list
note that running fpcmake and then make and then make install and see if it finds the package 'rtl' is a good test too. The ebuild changes I do right now fixes that issue hopefully :)
note, should change /units/linux/ to /units/i386-linux/ (what is the ebuild variable for the arch ? ${ARCH} ?)
Created attachment 49866 [details] the ebuild that works (beware, messy) the ebuild that works, added install stuff for the env.d entry and the config file did not rename "linux" -> "i386-linux" yet
note that i added a line to install a xpm file in the manual ebuild
Created attachment 49872 [details] the ebuild that works (beware, messy) linux -> i386-linux fixed diff call added sed for config file to replace $target by i386-linux (also added DEPEND)
Created attachment 49874 [details] filelist diff what is to do to the final version new misses list, for the new ebuild... seems to be zero... it actually installs too much... yay :)
Created attachment 49876 [details] default fpc.cfg, to be put into "files" new config files. has placeholders "$target". Since that is not supported by fpc (it was been supported though!?), simulated it by using sed (+DEPEND)
note that fpc -vut file.pas gives more detailed infos on why a unit was not used (otherwhise it will just say that the unit was "not found")
status report: - manual ebuild installs all files that make install would have too and some more - still found no way to prevent the bootstrapping compiler from trying /etc, /usr/lib (outside of the sandbox) - still needed other than that it should be fine
the Package.fpc generator does not find the other packages for some reason... grr... /usr/bin/fpcmake -p -Tlinux Makefile.fpc Processing Makefile.fpc Error: Target "linux", package "rtl" not found pyramid trunk # set |grep FPC FPCDIR=/usr/lib/fpc/1.9.7 why?
work it out fully and when you've completely tested it attach the fix.
that is a bug in cvs... have been told to always call 'fpcmake -Tall' (for all targets)... ugh
I think that package is too big (emerged it enough times now to know:)), hence splitting into smaller packages in bug#80104 (in parallel). I dont know which one I'll finally use so keep both bugs open for now.
We have stable releases and hardly the ressource to maintain what we have in Portage already.
