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

[Robin Cornelius]

On Feb 1, 2008 5:07 AM, Kamilion <kamilion at gmail.com> wrote:
> On Jan 31, 2008 2:45 PM, Robin Cornelius <robin.cornelius at gmail.com> wrote:
> > 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.
>
> If I'm not mistaken, isn't there an existing target to roll a full
> NSIS installer on windows anyway?

Really? ok if the package supports the NSIS installer then we should
support other installers too. I had missed that.

>
> I would very much like the option to generate full .deb packages
> directly from the source tree.
> Distros like Ubuntu will lag behind for up to 6 months on packages as
> they move through Debian's QA, then through Debian Sid, then Ubuntu
> will pick it up and include it in a dev release until it finally
> filters through down to the stable. This is fine for versions like
> 1.18.5.3 which was released in november and have hung around on the
> grid for a while, but we've got three MAJOR projects all gunning to be
> included in a release tree this year: Windlight, Havok4 and Mono. I
> seriously doubt debian or ubuntu will bother to spend the time
> releasing the RCs, beta grid viewers, firstlooks, or other minor
> releases that would vastly increase the tester user base on linux and
> allow bugs, quirks, and issues to be discovered quickly.

The thing is, *if* we have a make install target for linux that
respects FSH data locations etc, its trivial to build debs or RPMS,
the checkinstall command will roll a DEB or RPM based on a make
install target and no additional effort is required, we just need to
make install target to "do the right thing"

>
> It also opens the path down the road for Linden Labs to generate their
> own .deb repository which we can just add to our sources list, which
> solves autoupdate on debian-flavored linux by deferring it to the
> package manager. Gentoo mostly handles it themselves by running the
> build directly, and I'm not quite sure how Fedora goes about things as
> I havn't used a redhat release since 4.2.

Well that would be cool to have the Lindens run a repository save my
bandwidth. There are subtitle issues though. llmozlib is a PITA. I try
to package it as a separate shared library, this is fine on Debian but
some Ubuntus have a broken firefox build and its not possible to
install xulrunner-dev and firefox as theres a conflict. I suppose the
answer here is to to what the Lindens do now and roll llmozlib with
the slviewer-bin then there is no such dependency.
This would be fine for a linden release and probably be benifical if
different RC's, betas etc possibly use different llmozlibs?

The other issue is that there would need to be some way of specificy
the "application name" on the build line too. So that the target does
not necessarly get called secondlife-bin but can be renamed by the
user secondlife-windlight-r1234-bin etc.. AND the
/usr/share/secondlife folder would also need to be the same that way
multiple parallel installations can happen.

>
> Plainly, it allows us hacker types to generate custom .deb packages
> for all the 3rd party viewer 'hacks' that float around like nicholaz's
> real easy.
>
> Perhaps a secondlife-deb target in addition to secondlife-bin target?

I would vote firstly for a make install target, then this can be a
wrapped with a very simple additional target on top to create a
secondlife-deb or a secondlife-rpm

Kamilion: You make a very good argument for a secondlife-deb target.


Robin