All 3 points that Nathan makes are good.<br><br>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.<br>
<br>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.<br>

<br>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.<br>
<br>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.<br>
<br>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.<br>
<br>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.<br><br><br>Morgaine.<br><br><br><br>====================<br><br><div class="gmail_quote">
On Sat, Jun 18, 2011 at 1:44 AM, Nathan Lay <span dir="ltr"><<a href="mailto:nslay@comcast.net" target="_blank">nslay@comcast.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

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).<br>


<br>
So far, I've run into some irritations that make porting more difficult, namely: STANDALONE, python and glh<br>
<br>
1) STANDALONE<br>
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?<br>


<br>
2) Python<br>
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.<br>


<br>
3) glh<br>
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).<br>


<br>
Best Regards,<br><font color="#888888">
Nathan Lay<br>
_______________________________________________<br>
ImpDev mailing list<br>
<a href="mailto:ImpDev@lists.imprudenceviewer.org" target="_blank">ImpDev@lists.imprudenceviewer.org</a><br>
<a href="http://lists.imprudenceviewer.org/listinfo.cgi/impdev-imprudenceviewer.org" target="_blank">http://lists.imprudenceviewer.org/listinfo.cgi/impdev-imprudenceviewer.org</a><br>
</font></blockquote></div><br>