This is an update of the madman ebuild to the newest upstream version (0.93). From 0.91.1 (the current gentoo-version) to 0.93 madman have changed from using autoconf/automake to scons. This gives quite a lot of problems with the sandbox, as scons tries to create .sconsign and .scons$PID files in the include and library directories referenced by it. In order to prevent the sandbox from complaining about these, all these libraries are included in the predict path. Also the install target did not support having another installation directory than /, so the installation is coded in the ebuild. Since the madman source package includes a copy of scons to run locally, I have not added scons as a dependency of madman, but instead used the included version of scons. If anyone has an easier way to beat scons into submission, I am all ears ;-)
Created attachment 32523 [details] The new ebuild for madman-0.93
scons SUCKS. I have absolutely NO idea why any of the upstream providers are going with it.
what was wrong with "our" scons?
Klaus: Can you pleasse rewrire the ebuild to use our scons?
Sure, but I don't really see the point? Since scons is included in the madman source files, I thought that instead of having a dependency to install scons in order to compile madman, it would be nicer for the user to just use the one included in the package?
added to portage, but -amd64
This one may prevent from compiling (propably path name resolving issue) Not too critical though, because it's mentioned in the FAQ on sf <quote> Q: Why does SCons say "No tool named 'qt'"? Jon Burgess says, start SCons with "$PWD/scons.py" instead of "./scons.py". </quote> So I would suggest: 51c51 < $PWD/scons.py ${MAKEOPTS} prefix=/usr || die --- > ./scons.py ${MAKEOPTS} prefix=/usr || die
