|
everything ok with latest release on 64-current :hattip:
|
Just a question - is this normal when 'src2pkg -X -A -DEST' command with '-N'-generated and unmodified qmmp.src2pkg.auto script sets that -DCMAKE_INSTALL_PREFIX:
Code:
Notice - The configuration files are in a subdirectory: qmmpCode:
m@masin:~$ qmmp At the same time something also happened with src2pkg packaged 'partitionmanager' which also worked earlier, but now is giving this error: Code:
bash-3.1# partitionmanagerCode:
/usr/bin/partitionmanager It very well might be something in my box, because i have kdm crashing upon restart of a computer, so that i do 'Alt+F6', login as root, telinit 3 and telinit 4 to get into X and KDE. |
Oh boy! Here we go again with cmake!
Is partitionmanager also using cmake? What version of cmake do you have installled. Try this and see ifit fixes it -I don't have QT-4 installed right now in order to check this: cd into /usr/libexec/src2pkg and make a copy of 06-configure_source Then open the original and go down to line 622 and change this: Code:
CMAKE_OPTIONS=$(echo -DCMAKE_INSTALL_PREFIX:PATH="${PKG_DIR}/${PRE_FIX}" -DLIB_SUFFIX=${LIBDIRSUFFIX} -DCMAKE_BUILD_TYPE=Release ${EXTRA_CONFIGS} |white_out )Code:
CMAKE_OPTIONS=$(echo -DCMAKE_INSTALL_PREFIX:PATH="/${PRE_FIX}" -DLIB_SUFFIX=${LIBDIRSUFFIX} -DCMAKE_BUILD_TYPE=Release ${EXTRA_CONFIGS} |white_out ) |
With all different configurations is still wise continue to develop src2pkg? I use the 1.9 version and I like it. I hope that gnashley could do the same on 2.1.
EDIT: I upgraded to 2.1 and the tar error don't appears anymore. And all src2pkg --setup "tests" give it ok to me. I hope that now src2pkg will work fine. Thanks. |
I've restarted again to see if this problem reappear as it once did. But for now qmmp is fine.
Partitionmanager mystically 'got healed' after i reinstalled it, checked to see that it didn't really fix the problem, then recompiled the program with 'src2pkg partitionmanager-1.0.1.tar.bz2' but before even installing the newly created package i tried (just in case) to launch the app once more and it fired up. After restart previously posted error is back. So if you, Gnashley, think this is build problem rather than something fishy with my computer i'll modify the '06-configure_source' and recompile using the same command as earlier(?). And, to mention, i'm using fully updated slackware64-current. |
Well, I'm not sure it is 'wise' to do such development, but it is usually a bit of fun and good for keeping my old brain active. I do wish that cmake had not been invented, though, as supporting it has been a royal pain from the very first. I could quit working on src2pkg at any point, but if I had quit at 1.9, then anyone running Slackware current would be stuck -they'd have to downgrade or keep an old stable-13.0 installed in order to be able to build src2pkg itself -assuming that if built on an old OS it would run on the newer one -but that is not always the case.
I'd be happy if everything on our OS was not a moving target, but other folks like having their 'fun' too, so things move along whether I like it or not. Unfortunately, the 'latest' is not always the 'greatest' at a given moment -even for src2pkg. As you have discovered the last few days when *you* were better off with an older stable version. But it was *others*, who suddenly found that 2.0 wouldn't build on current who caused me to scramble to fix the problems -I had to update to the latest glibc and gcc on my development box in order to duplicate the problems. Very glad that you have reported success with the latest build of 2.1 -now I must go fix the cmake problem ...again. I may have to write code which checks the version of cmake being used and have a separate routine for each of cmake-2.4, 2.6(but less than 2.6.2) and 2.8 as each of them behaves a different way regarding CMAKE_INSTALL_PREFIX and DESTDIR. Either that or onyl support the 'latest greatest' version of cmake... Are we having fun yet? |
This: "launch the app once more and it fired up. After restart previously posted error is back" is exactly the case. cmake and other build systems have to do something special when 'installing' a program -running a compiled program from the directory where it si compiled is not the same as running it from its *installed location*. It has to do with the linking of libraries and is too compley to try to explain here. Suffice it to say that the fact that the program will run from the compile location does not mean that it will run from the installed location.
I'll have to try and find some more sources which use cmake and run more tests to see if I can find a more definitive fix. The problem is that sources which have been prepared to be built using cmake-2.4 or cmake-2.6.(0 or 1), will not always respond the same as sources which have been correctly setup to be built using cmake-2.6.2 or 2.8. src2pkg used to work fine with cmake-2.4, until 2.6 came along. Then it was fixed for 2.6, but not 2.4. Maybe now it will consistently *not* work for any version of cmake.... Oh yes, we are having fun! |
in my opinion, experimenting/improving is always fun :D
cmake is superLOL (trying to mitigate the drama) |
This time command 'bash-3.1$ src2pkg -b=2 /home/m/Download/partitionmanager/partitionmanager-1.0.1.tar.bz2' failed with:
Code:
Found source archive: partitionmanager-1.0.1.tar.bz2 |
It's really strange how badly CMake's been behaving for installs.. when I'm in "normal upstream dev" mode it handles everything else really, really well.
|
Oh, i get it, partitionmanager was working till i haven't deleted the build directories from /tmp.
|
Here's what should be the definitive fix for the cmake prefix problems, no matter what version of cmake is being used:
fix-cmake-for-good.diff Code:
--- ./06-configure_source.00 2010-01-17 11:26:42.000000000 +0100cp fix-cmake-for-good.diff /usr/libexec/src2pkg cd /usr/libexec/src2pkg patch -p0 < fix-cmake-for-good.diff rm fix-cmake-for-good.diff It does mean you'll have to be root to create the package, though. Any other fix for this would depend on detecting the version of cmake, but would probably still break sometimes if the sources were written to work with some other version of cmake than that being used. |
Yep, now as root it created the proper tgz. And i didn't see the -DCMAKE_INSTALL_PREFIX with path '/tmp/.../usr' anywhere in the log any more, also.
Thanks a lot! |
The fix (INSTALL_TYPE=SAFE) makes it install everything to the real root filesystem while tracking the file creation. It could use INSTALL_TYPE=REAL which is nearly the same thing, except SAFE backs up any files which might be overwritten and then restores them. It's unfortunate that you have to be root, but I don't see another way to make it work consistently -maybe in a couple of years when we might assume that everyone is using cmake newer than 2.6.1 -and only then if cmake finally settles on a single way of handling DESTDIR.
Thanks for reporting your problem so it could be fixed. |
| All times are GMT -5. The time now is 02:08 AM. |