after a while dealing with other matters I'd like to once again build and test the latest version of Lprof. In the meatime I switched Macs, so I'm starting from scratch.
Hal,
is the recommended way to build Lprof still scons?
Rishi,
I still have my notes from earlier build - but in the meantime I believe some things might have changed.
Would you be so kind to send me your latest notes? That could help a lot.
Thanks in adwance.
Regards
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Although there is a cmake build that is part of the source code tree there are still a few loose ends in the cmake build that need to be taken care of. So at this point scons is the official way to do the build although with a few hand steps the cmake build will also work. Specifically to get the cmake build to work you must build the translations by hand and put them in the correct directory before running cmake. I think version 2.6 of cmake, which is now the released version, has support for doing Qt translations which was missing from 2.4.
Also in the mean time I have learned that there are issues related to the stock libusb library. There are patches available for linux but these have had the OS/X and Windows specific changes needed to make the ArgyllCMS meter libraries work with all meters stripped out. There is work underway to get this patch set accepted by various Linux distros since the libusb folks are not willing to apply it or any of the other changes that have been made by the ArgyllCMS developer. The ArgyllCMS source tree has a version of libusb that is patched for every OS and you should use this with LProf as well on OS/X. This is for sure needed for EyeOne Pro users and it may affect other meters as well although I don't know which ones and on what platforms since this has not been needed for any of the meters I have tested (but I don't have an i1 pro and I don't have an OS/X machine). As far as I know the ArgyllCMS libusb changes have been stable since about version 0.70beta1 so the libusb code from ArgyllCMS 1.0.1 should be OK.
ArgyllCMS 1.0.1 shipped a few weeks ago and as soon as it stabilizes I will be migrating to that version of the ArgyllCMS code base. It is getting closer but I have found some bugs and so have others and I suspect that it will be a few more weeks before fixes for those are available.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I successfully compiled LProf on OS X 10.5.1 using the cmake build. I was not able to using scons.
I wrote down most of the protocol for a successful compile, but am missing some crucial steps. I plan on recompiling on a separate hard drive that just has OS X cleanly installed... just to get the technique down. As I do that, I'll write a new set of instructions, and send that to you, or post it here.
Just give me a little bit -- I've been MIA primarily due to a nasty viral bug that lasted weeks!
Cheers,
Rishi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Get well. I have also been somewhat side lined of late with heath issues but I am on the mend now.
Craig is the one who put the cmake build together. At the point where he stopped working on it is was mostly functional but we had issues with version 2.4 with some features that we needed that were missing. Now that cmake 2.6 has been released I believe that the issues we were having with translations and perhaps a few other things may be fixable. I will contact Craig and ask him to have another look at cleaning up the cmake build. Even though scons is a good build system at this point I think cmake is better particularly for Qt (and KDE) builds and I would like to get the cmake build fully sorted out and move to it as the official build tool for LProf.
Your notes on what you needed to do to get the cmake build working on OS/X would be helpful for understanding what needs to happen to make the cmake build fully functional. Please post it here since it will help other users and in the long run will help us sort things out. In addition some of it may be used to improve our build docs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been keeping an eye on discussion, but (speaking of sidelined) I've been pretty flat out with work lately. That situation is likely to continue for some time, but I'd be happy to make some time to work on lprof's build tools if there's anything I can do to be useful.
The CMake code was primarily intended to ensure that win32 builds worked well with both MinGW and VC++. SCons isn't very appealing on win32 (OK, win32 isn't very appealing either, but sometimes you're stuck with working on it). However, I just ran out of time to work on it.
I'll try to get a VM set up for win32 dev and re-test with the latest HEAD.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think there were three outstanding issues with the cmake build that applied to all platforms.
1. The support for handling translations was not working correctly with cmake 2.4. Users needed to either run the scons build to create the translation files or they had to do this by hand before the build would complete successfully. I think the Qt related translation stuff in cmake 2.6 should be working (I think this was added in one of the 2.6 beta releases). In fact with cmake 2.6 the translation part of the build is mostly working but some some reason it did all of the translations except Russian. But that should be simple to fix. This is only working for in tree builds see #2.
2. There is an issue with the qrc file where the translations are failing to build when building out of tree. When building out of tree I get:
make[2]: *** No rule to make target `../../translations/lprof_de.qm', needed by `src/qrc_lprof.cxx'. Stop.
If I build far enough with the scons build that the translations are created then the out of tree cmake build works. This issue and #1 may be related since it appears that the building of the *.qm files is being triggered by the lprof.qrc file and I suspect that if the build of the translations where explicitly coded into the cmake build that this stuff might start working.
3. There is also an issue with how LProf finds things when being run from some place other than <prefix>/bin. That is when it is being run from the build directory it expects to find things in specific locations relative to the location of the executable since the executable expects to be located in build/<platform> and it expects to find help files in ../../data/help/<LANG> for example. This used to be true for additional things like the translations and graphics for the old Qt3 versions but these are now included as resources which greatly simplifies installation and makes the location of these files a non-issue. But the help files and templates are still affected by this and I am not sure that it makes sense to make these into resources. Although that would solve this problem and also make installation simpler at the expense of a larger executable. What do you think?
With the scons build it was simple to control the location of the build directory which made it possible to know where things like the help files where located when a user ran lprof from the build directory. But with cmake the user can do the build in any directory they choose. Unless there is a way to force a fixed build directory structure like there is in scons.
In any case none of these issues are a big deal. They just need to be dealt with.
I found that scons on win32 with MinGW worked nicely. Once I got it working with MinGW I didn't bother with VC++ because I didn't want to deal with it since I was not using it. But I think it would be nice to have a VC++ build working for those users that want to use VC++. I also found that scons was not as forgiving on win32 as it was on *nix platforms. That is on win32 I found a lot of things that were in fact bugs in the scons build but that still worked on *nix platforms. But you are right that cmake is cleaner on win32. Initially if we can get good clean *nix, OS/X and MinGW builds I would be happy to cut things over to cmake and remove the scons builds. VC++ support can then be added later as time permits.
So at this point there are still some issues with translations, out of tree builds and how to handle running lprof from locations other than build/<platform> and <prefix>/bin to resolve. Once those are working I think we can cut over to cmake.
Hal
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Hal, Rishi
after a while dealing with other matters I'd like to once again build and test the latest version of Lprof. In the meatime I switched Macs, so I'm starting from scratch.
Hal,
is the recommended way to build Lprof still scons?
Rishi,
I still have my notes from earlier build - but in the meantime I believe some things might have changed.
Would you be so kind to send me your latest notes? That could help a lot.
Thanks in adwance.
Regards
Mark
Mark,
Although there is a cmake build that is part of the source code tree there are still a few loose ends in the cmake build that need to be taken care of. So at this point scons is the official way to do the build although with a few hand steps the cmake build will also work. Specifically to get the cmake build to work you must build the translations by hand and put them in the correct directory before running cmake. I think version 2.6 of cmake, which is now the released version, has support for doing Qt translations which was missing from 2.4.
Also in the mean time I have learned that there are issues related to the stock libusb library. There are patches available for linux but these have had the OS/X and Windows specific changes needed to make the ArgyllCMS meter libraries work with all meters stripped out. There is work underway to get this patch set accepted by various Linux distros since the libusb folks are not willing to apply it or any of the other changes that have been made by the ArgyllCMS developer. The ArgyllCMS source tree has a version of libusb that is patched for every OS and you should use this with LProf as well on OS/X. This is for sure needed for EyeOne Pro users and it may affect other meters as well although I don't know which ones and on what platforms since this has not been needed for any of the meters I have tested (but I don't have an i1 pro and I don't have an OS/X machine). As far as I know the ArgyllCMS libusb changes have been stable since about version 0.70beta1 so the libusb code from ArgyllCMS 1.0.1 should be OK.
ArgyllCMS 1.0.1 shipped a few weeks ago and as soon as it stabilizes I will be migrating to that version of the ArgyllCMS code base. It is getting closer but I have found some bugs and so have others and I suspect that it will be a few more weeks before fixes for those are available.
Hi Mark & Hal,
I successfully compiled LProf on OS X 10.5.1 using the cmake build. I was not able to using scons.
I wrote down most of the protocol for a successful compile, but am missing some crucial steps. I plan on recompiling on a separate hard drive that just has OS X cleanly installed... just to get the technique down. As I do that, I'll write a new set of instructions, and send that to you, or post it here.
Just give me a little bit -- I've been MIA primarily due to a nasty viral bug that lasted weeks!
Cheers,
Rishi
Rishi,
Get well. I have also been somewhat side lined of late with heath issues but I am on the mend now.
Craig is the one who put the cmake build together. At the point where he stopped working on it is was mostly functional but we had issues with version 2.4 with some features that we needed that were missing. Now that cmake 2.6 has been released I believe that the issues we were having with translations and perhaps a few other things may be fixable. I will contact Craig and ask him to have another look at cleaning up the cmake build. Even though scons is a good build system at this point I think cmake is better particularly for Qt (and KDE) builds and I would like to get the cmake build fully sorted out and move to it as the official build tool for LProf.
Your notes on what you needed to do to get the cmake build working on OS/X would be helpful for understanding what needs to happen to make the cmake build fully functional. Please post it here since it will help other users and in the long run will help us sort things out. In addition some of it may be used to improve our build docs.
I've been keeping an eye on discussion, but (speaking of sidelined) I've been pretty flat out with work lately. That situation is likely to continue for some time, but I'd be happy to make some time to work on lprof's build tools if there's anything I can do to be useful.
The CMake code was primarily intended to ensure that win32 builds worked well with both MinGW and VC++. SCons isn't very appealing on win32 (OK, win32 isn't very appealing either, but sometimes you're stuck with working on it). However, I just ran out of time to work on it.
I'll try to get a VM set up for win32 dev and re-test with the latest HEAD.
Craig,
I think there were three outstanding issues with the cmake build that applied to all platforms.
1. The support for handling translations was not working correctly with cmake 2.4. Users needed to either run the scons build to create the translation files or they had to do this by hand before the build would complete successfully. I think the Qt related translation stuff in cmake 2.6 should be working (I think this was added in one of the 2.6 beta releases). In fact with cmake 2.6 the translation part of the build is mostly working but some some reason it did all of the translations except Russian. But that should be simple to fix. This is only working for in tree builds see #2.
2. There is an issue with the qrc file where the translations are failing to build when building out of tree. When building out of tree I get:
make[2]: *** No rule to make target `../../translations/lprof_de.qm', needed by `src/qrc_lprof.cxx'. Stop.
If I build far enough with the scons build that the translations are created then the out of tree cmake build works. This issue and #1 may be related since it appears that the building of the *.qm files is being triggered by the lprof.qrc file and I suspect that if the build of the translations where explicitly coded into the cmake build that this stuff might start working.
3. There is also an issue with how LProf finds things when being run from some place other than <prefix>/bin. That is when it is being run from the build directory it expects to find things in specific locations relative to the location of the executable since the executable expects to be located in build/<platform> and it expects to find help files in ../../data/help/<LANG> for example. This used to be true for additional things like the translations and graphics for the old Qt3 versions but these are now included as resources which greatly simplifies installation and makes the location of these files a non-issue. But the help files and templates are still affected by this and I am not sure that it makes sense to make these into resources. Although that would solve this problem and also make installation simpler at the expense of a larger executable. What do you think?
With the scons build it was simple to control the location of the build directory which made it possible to know where things like the help files where located when a user ran lprof from the build directory. But with cmake the user can do the build in any directory they choose. Unless there is a way to force a fixed build directory structure like there is in scons.
In any case none of these issues are a big deal. They just need to be dealt with.
I found that scons on win32 with MinGW worked nicely. Once I got it working with MinGW I didn't bother with VC++ because I didn't want to deal with it since I was not using it. But I think it would be nice to have a VC++ build working for those users that want to use VC++. I also found that scons was not as forgiving on win32 as it was on *nix platforms. That is on win32 I found a lot of things that were in fact bugs in the scons build but that still worked on *nix platforms. But you are right that cmake is cleaner on win32. Initially if we can get good clean *nix, OS/X and MinGW builds I would be happy to cut things over to cmake and remove the scons builds. VC++ support can then be added later as time permits.
So at this point there are still some issues with translations, out of tree builds and how to handle running lprof from locations other than build/<platform> and <prefix>/bin to resolve. Once those are working I think we can cut over to cmake.
Hal