Re: [Celestia-developers] The liblua*.so mess, ADDENDUM
Real-time 3D visualization of space
Status: Beta
Brought to you by:
cjlaurel
From: Fridger S. <fri...@de...> - 2012-03-31 11:46:10
|
Hi Andrew, Pat, funny... I was just "breeding" as well over a possible synthesis of my original code idea and the pkgconfig-based code by Pat. Let me just inject a few further considerations of mine: 1) Meanwhile, I consider the pkgconfig-based approach slightly superior to mine, since a) qmake supports it generally, implying that we can easily generalize Pat's code to further eliminate possible notation ambiguities among different Linux distros! It basically amounts to extending the PKGCONFIG list, e.g. PKGCONFIG += $$LUAPC $$OGGPC $$DBUS-1PC etc I examined lots of different distros and learned that indeed, pkg-config support is now mostly implemented. b) There is actually an error message appearing if the user forgot to install any lua library (i.e if no lua.pc file was found after starting qmake.) c) Include and library dirs are automatically adapted as well. 2) Since many distros already offer lua 5.2, we should include a whole range of lua VERSIONS as well in our current coding attempts. Here my loop approach could come in handy.. a) First of all, of course, we need to check whether the Celestia code shows any incompatibilities with lua 5.2. Today I upgraded to lua 5.2 without seing any immediate problems so far. LUA_VER-dependent code resides in celestia/celx.cpp and in celephem/scriptobject.h b) We should limit the acceptable range of lua versions e.g. between 5.0 and 5.2. Note that we may include inequalities / constraints into the !system(pkg-config --exists ...) command and | or use --atleast-version=VERSION, --max-version=VERSION. Depending on the success of these constraints pkg-config and thus !system() exits with true or false c) we have to adapt the LUA_VER in line further below in celestia.pro: DEFINES += CELX LUA_VER=0x050100 Fridger On 03/31/2012 12:03 PM, Andrew Tribick wrote: > Hello, > > Fridger's file from 29 March does not work on Ubuntu. Pat's does. I do > like the error notification and loop approach from Fridger's file > though: in case we find we do need another option it lends itself > slightly better to extensibility. > How about the following? > > unix { > CONFIG += link_pkgconfig > > LUALIST = lua5.1 lua > for(libpc, LUALIST):system(pkg-config --exists $${libpc}):LUAPC = $${libpc} > isEmpty (LUAPC) {error("No shared Lua library found!")} > > PKGCONFIG += $$LUAPC > INCLUDEPATH += /usr/local/cspice/include > LIBS += -ljpeg /usr/local/cspice/lib/cspice.a > } > > Regards, > Andrew > > On 30 March 2012 22:11, Fridger Schrempp<fri...@de...> wrote: >> Pat, >> >> >> On 03/30/2012 09:10 PM, Pat Suwalski wrote: >> >> On 30/03/12 02:39 PM, Fridger Schrempp wrote: >> >> While you a presumably dreaming of pkgconfig at night ;-) (given your >> Linux history...), I can assure you that in KDE4 based desktops >> pkgconfig does NOT play a significant role at all! Hence a significant >> number of Linux users will not even have pkgconfig installed and errors >> would be thrown at them after starting qmake. My version is more >> elementary i.e. it does not invoke any auxiliary programs whatsoever. >> Many KDE4 users might never have heard what *.pc files are etc. >> >> I respectfully disagree. You can't even build KDE4 without pkgconfig. >> Also, it's in every distro's repository. Qt actually ships with .pc files. >> >> Most users don't build KDE4. However, it is indeed true that the lua-devel >> archive and the Qt distro of openSuSE 11.x also contain .pc files. >> >> Anyhow, it is functionality that qmake supports natively >> (CONFIG+=link_pkgconfig), so I think it's acceptable to use it. >> >> It is certainly acceptable to use pkgconfig, but I still doubt that the >> specific code is superior. >> Let's wait for further explicit tests by our friends. >> >> My syntax using directly the various occuring liblua names is >> selfexplanatory without being inferior in performance. >> >> Incorrect. It is very inferior in performance. >> >> Here is the explicit check, using >> >>> time qmake -config release ../src/celestia.pro >> RESULT: ;-) >> >> your code: >> ============ >> real 0m0.574s >> user 0m0.433s >> sys 0m0.134s >> >> my code: >> =========== >> real 0m0.566s >> user 0m0.435s >> sys 0m0.126s >> >> So do you still think my code (with my liblua notation being placed last in >> the loop!) is >> >> "very inferior in performance" >> >> You missed the part that my code adds the INCLUDE path and actually >> works. Yours will not build for most users of Linux, because the >> libraries aren't in /usr/lib and the includes aren't in /usr/include. >> >> I refuse Linux distros that don't use the UNIX standard /usr/lib and >> /usr/include for their repository stuff that generally includes liblua ;-) >> Of course, I can easily fix the include issue in my code. >> >> Fridger >> >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> _______________________________________________ >> Celestia-developers mailing list >> Cel...@li... >> https://lists.sourceforge.net/lists/listinfo/celestia-developers >> > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers |