The prefix is right, but libdir is not - at least in a few seldom cases. The qmake files check for `uname -m` being x86_64, which is ok as a default, but ultimately cannot reliably put libraries to where to distro puts them, as only distro build scripts know where that will be.
The number of items in the completed section of the to-do list hasn't increased for a while and I notice that in the 'stuff left to do' section, only Dani has been assigned to some items but Skyjake hasn't (I'm guessing real life is occupying him, IIRC from the weekly update).
The to do list is only for issues that exist in released builds. Things Deng team are working on in private branches aren't included on that list unless further work is needed on them after they are added to an unstable build.
For instance, a new feature that Skyjake was previously working on in a private branch was added to the latest unstable build (all those 'updater' commits); try opening the console and typing 'update'. Hence now it is in an unstable build, we may see things about it (i.e issues, bug fixes and tweaks) added to the to do list.
Skyjake has been mentioning he's been working on it in the last few weekly developer updates.
The prefix is right, but libdir is not - at least in a few seldom cases. The qmake files check for `uname -m` being x86_64, which is ok as a default, but ultimately cannot reliably put libraries to where to distro puts them, as only distro build scripts know where that will be.
In your situation, what would be the appropriate libdir? (and what is it giving you at the moment?) We could fix the logic for determining DENG_LIB_DIR, or we could add a way to manually override it at compilation time.
In your situation, what would be the appropriate libdir? (and what is it giving you at the moment?) We could fix the logic for determining DENG_LIB_DIR, or we could add a way to manually override it at compilation time.
You cannot determine libdir - but you can keep the default -, there ought to be a way to override it. http://stackoverflow.com/a/10140985/1091587 has a write-up as well.
Please also consider fixing the qmake scripts such that `qmake QMAKE_CFLAGS+=-m32 QMAKE_CXXFLAGS+=-m32 QMAKE_LFLAGS+=-m32` yields success. Right now, -m32 is not added to the link lines. Maybe it's qmake, maybe it's due to *.pro (in either case, this is what the AM proponents say, and I can agree)
I: Program causes undefined operation
(likely same variable used twiceand post/pre incremented in the same expressi
on).
e.g. x = x++; Split it in two operations.
W: doomsday sequence-point portable/src/generators.c:214
[...]
Comments
For instance, a new feature that Skyjake was previously working on in a private branch was added to the latest unstable build (all those 'updater' commits); try opening the console and typing 'update'. Hence now it is in an unstable build, we may see things about it (i.e issues, bug fixes and tweaks) added to the to do list.
Skyjake has been mentioning he's been working on it in the last few weekly developer updates.
There already is a way to manually override libdir at runtime.
Please also consider fixing the qmake scripts such that `qmake QMAKE_CFLAGS+=-m32 QMAKE_CXXFLAGS+=-m32 QMAKE_LFLAGS+=-m32` yields success. Right now, -m32 is not added to the link lines. Maybe it's qmake, maybe it's due to *.pro (in either case, this is what the AM proponents say, and I can agree)