Am Montag, 18. Dezember 2006 16:19 schrieb Bo Peng: > > I still have to comment line 348 in development/scons/qt4.py. If I do that > > the linking step succeeds. > > Although your qt installation has to be blamed. I have modified > SConstruct to accommendate this.
Why should my qt installation be blamed? It is an absolute standard installation on debian, and on SuSE it looks alike. IMO a build system should work with such standard installations without any tweak or commandline argument (I still need to give qt_lib_path=/usr/lib), especially since pkg-config provides all necessary information. > > ~/lyx-1.5/build-tree-scons$ ./lyx -dbg init > > Checking whether LyX is run in place... no > > Unable to determine the system directory having > > > Of course I could install, but I don't want to. I usually configure for > > installation on a server where I don't have direct write permissions, > > therefore I have to install into a temp DESTDIR. Of course I can't run > > from the DESTDIR, that means that I would need to configure for different > > builds with scons, depending on whether I want to do a final install or > > just run it. That means that scons is not usable for me currently. > > I do not quite understand, > > 1. What autotools have done for you that allows you to start lyx from > any VPATH build? I don't use VPATH, and this has nothing to do with autotools magic. The code in support/package.C.in does not find its support directories, therefore LyX aborts. > 2. Why cannot you use options like --sysdir? Too much typing for debugging. > 3. Install to the same DESTDIR is not a big deal because only the lyx > executable will be replaced when you install from different builds, > unless you want to compare different lyx builds side by side. That is not the problem. The problem is that LyX will refuse to start if I install it into a DESTDIR and run it from there. It will only run from the final destination dir, because it won't find its support files. > I guess I can not help you here. Then I continue to use the autotools. Scons might work on windows, but as you can see there are still many problems on Linux. > > I see that is also tries 1.34 now, very nice. But anyway, if I install the > > 1.33.1 devel packages, I get: > > > > Checking for boost library signals, regex, filesystem, iostreams... > > Warning: Can not find an appropriate boost library in /usr/lib. > > Allowed versions are 1_33_1, 1_34 > > Use library /usr/lib/libboost_signals-gcc-mt-1_33_1.a > > Warning: Can not find an appropriate boost library in /usr/lib. > > Allowed versions are 1_33_1, 1_34 > > Use library /usr/lib/libboost_regex-gcc-1_33_1.a > > Warning: Can not find an appropriate boost library in /usr/lib. > > Allowed versions are 1_33_1, 1_34 > > Use library /usr/lib/libboost_filesystem-gcc-1_33_1.a > > Warning: Can not find an appropriate boost library in /usr/lib. > > Allowed versions are 1_33_1, 1_34 > > Use library /usr/lib/libboost_signals-gcc-mt-1_33_1.a > > Warning: Can not find an appropriate boost library in /usr/lib. > > Allowed versions are 1_33_1, 1_34 > > Use library /usr/lib/libboost_regex-gcc-1_33_1.a > > Warning: Can not find an appropriate boost library in /usr/lib. > > Allowed versions are 1_33_1, 1_34 > > Use library /usr/lib/libboost_filesystem-gcc-1_33_1.a > > > > This output is confusing: Does it use the found libraries, or not? (later I > > see that it does not). And IMHO the shared libraries should be preferred > > over the static ones (I have installed both). > > Under mode=debug, scons is looking for libboost_regex_gcc-d-1_33_1.a > (or mt-d, or -g, or -y). If they are not found, release libraries are > used. If the found libraries are not used later, it is a scons bug. > The shared libraries should be used, given the command line > -lboost-regex-1_33_1. Actually it did not use either (but the internal boost version as I found out later). I only guessed from the messages it gave that it would use the static libraries, but that was not true. > In summary: scons tries to use the debug version of qt and boost > libraries under mode=debug, and tries to check the exact boost version > (it checks library names and opens boost/version.hpp to check for > version string) before using it. It does still not find boost 1.33.1, and gives the same confusing error messages as cited above. > It autotools do not link to the debug > version and allow boost 1_35 (cvs) to be used (it can not be used > actually), autotools would better be improved. I ask again: Why would I want to debug boost or qt if I want a debug version of LyX? This is normally not needed in my experience. And even if it was: If you don't compile a library yourself there usually is no debug version. Although I don't like to use debug libraries it would not mind scons searching them, as long as it correctly falls back to the non-debug versions if it does not find the debug version. Yes, autotools do not check the boost version at all. That should be improved, but since using the included boost is the default for autotools this is not such a high priority. Georg
