[impdev] Porting to FreeBSD ... and irritations

[Morgaine]

All 3 points that Nathan makes are good.

No doubt the Impy devs will provide a more specific answer, but from the
sidelines after observing and using the viewer build process for many years,
this is my take on it.

It all boils down to:  (i) Linden Lab did it, and (ii) despite making little
sense, it's less work to use their contrived build system than to create a
new clean one from scratch.  Those two reasons are probably the full story.

Certainly the "standalone" concept as a build option is beyond daft (quite
apart from its reverse-logic naming --- packaged libs make a package
logically standalone, the opposite of LL's terminology).  All sensible build
systems use platform libs if available anyway --- even Linden's "prebuilt"
builds use glibc and they don't try to package it, as that would be doomed
to failure.  Whether additional binary libs are packaged together with a
viewer or not should not impact on the build system anyway, only on final
packaging choice.

In a saner world not designed by LL, prebuilt libs wouldn't be part of the
viewer package at all.  Instead, the launch script would check whether
required libs exist on the client machine natively, and those that don't
exist would be downloaded to the viewer's persistent prebuilts directory.
This would happen ONCE, or only after the user has flushed her prebuilt libs
cache manually.

That approach would make downloads nice and slim, and it would totally
eliminate the standalone/prebuilts distinction.  A machine that has all the
libs installed natively would never need to download a prebuilt lib on
launch at all.

As a final point, if virtual worlds are going to take off, viewers need to
be distro-friendly, and the prebuilts system is not.  This needs to change.


Morgaine.



====================

On Sat, Jun 18, 2011 at 1:44 AM, Nathan Lay <nslay at comcast.net> wrote:

> So, I'm working on porting this to FreeBSD for fun ... luckily all code
> I've come across for LL_LINUX, LL_SOLARIS and LL_DARWIN apply to directly
> FreeBSD (for POSIX and BSD reasons) so it hasn't been terribly difficult so
> far. I can build up to 30% of the entire project now (not sure it actually
> _works_ though).
>
> So far, I've run into some irritations that make porting more difficult,
> namely: STANDALONE, python and glh
>
> 1) STANDALONE
> You use the CMake build system ... why in the world would you need to
> distinguish the build as a standalone build or not? It's trivial to direct
> CMake to the right paths with the curses 'ccmake' and cmake-GUI on Windows
> ... so why complicate the configuration process and check for prebuilt
> libraries in strange directories in the non-standalone scenario, and for
> system libraries otherwise?
>
> 2) Python
> What's the point of using this to invoke cmake? Everything needed is
> already in CMake. You can make option variables (like STANDALONE for
> --standalone) and get the system platform and processor without needing
> python scripts.
>
> 3) glh
> This one is stumping me. I saw a header snippit ... written in 2000 and
> even includes template hacks (for when there were C++ compilers that may not
> have supported templates). It's virtually absent on the Internet ... it
> appears unmaintained and unused, so why is this relied upon? It seems to be
> distributed under a BSDL-like license so you could perhaps include it in
> Imprudence (which would be convenient since it seems to be hard to find).
>
> Best Regards,
> Nathan Lay
> _______________________________________________
> ImpDev mailing list
> ImpDev at lists.imprudenceviewer.org
> http://lists.imprudenceviewer.org/listinfo.cgi/impdev-imprudenceviewer.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.imprudenceviewer.org/pipermail/impdev-imprudenceviewer.org/attachments/20110618/f400bf1e/attachment-0002.htm>