[sldev] CMake preview available - please try it out!

Robin Cornelius robin.cornelius at gmail.com
Thu Jan 31 14:45:55 PST 2008


Phoenix wrote:
> 
> On 2008-01-31, at 11:06, Robin Cornelius wrote:
>>>> Hit loads of problems from the start.
>>>
>>> Well, yeah.  It's a first preview, after all :-)
>>
>> My issues are normally caused by wanting to do things the debian way so
>> that's to be expected too.
> 
> Thanks for jumping on this Robin.
> 
> The cmake team here is dedicated to delivering a build system that works
> for everyone as long as they are willing to run cmake. If you want to
> provide cmake.py patches which, through a command line option or
> command, do nearly everything necessary to set up a debianized build
> tree, we will probably roll it into our future releases.
> 
> Patches to the find apr script will also be welcome. :)


I am not sure that we need cmake to go as far as making Debian packages,
that would be the same on windows as it rolling the installer too. As
long as it produces all the binaries correctly and ideally without
patching the build code that's great. But there are probably a few extra
steps that could be done for linux users :-

1) arp headers, BOS is on the case :-) appears to be a Debian (Ubuntu?)
issue.

2) -Werror, again caused by newer GCC's warning on string conversions
from string constants to char *. Suggestion, short term suppress the
warning.

3) openjpeg headers

On debian they seem to be going to just /usr/include/openjpeg.h and not
/usr/include/openjpeg/opejpeg.h, one line patch in
/linden/indra/llimagej2coj/llimagej2coj.cpp. Sounds like an easy cmake
patch :-)


Things become less important after this and less to do with the build
environment.


4) App Read only data. Linux FSH and certainly Debian policy says that
application read only data should live in /usr/share/application_name/.
This is a simple patch to  linden/indra/llvfs/lldir_linux.cpp to change
-       mAppRODataDir = tmp_str;
+       mAppRODataDir = "/usr/share/secondlife";

Windows and Mac tend to keep their data and applications together,
unless you start using (windows) documents and settings/user/application
data/..... but most apps just install in program files/app_name and mac
keeps its stuff together in a different way. So this is a linux only
thing and only effects those who want a direct install. Any one just
building a replacment secondlife-bin or a tarball does not want to be
bothered by this and this is also only applicable if you are going to
package or install directly.

It might be nice to be able to adjust this variable from the build line
for packagers and default to what it is currently for others. I don't
think this is necessary however, a patch really is not a problem and is
not really related to the cmake side of things here.

With 1,2 and 3 done things just build now, any additional patching is
viewer source code changes and outside the scope of the cmake effort.

The only additional thing would be an install make target? this is
getting close to rolling an installer but on the other hand this is a
standard thing for a linux application compiling from source to do. With
4 above implemented a simple "make install" could drop the data in
/usr/share/secondlife/ and the binary in /usr/bin/ for example.

A compiling user could then use a wrapper make script to create a .deb
.rpm etc but this is never what a proper distributor of a .deb or rpm
would do as the package would need fine tuning that could not be
provided by that system.

It also seems a bit silly having the packaging handled upstream as then
any little tweaks to meet debian policy for example, would require
upstream patching/development time/ QA process. All of which is
unnecessary if the packaging is just handled by the packager.

I think what i am saying again is that if we can build cleanly without
patching then jobs done for cmake, but a couple of little "debian" or
"redhat" specific fixes (to move data locations etc) are no worries and
just things that are expected.

Robin


































-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080131/a8f4fa6c/signature.pgp


More information about the SLDev mailing list