[impdev] Porting to FreeBSD ... and irritations
Nathan Lay
nslay at comcast.net
Fri Jun 17 23:08:57 PDT 2011
I got it to build on FreeBSD! Unfortunately, it displays an error
message about a config file, fails to acquire locks, and then crashes
... now the ugly stuff. Then I guess I have to make all these changes to
1.4 (I ported 1.3.2).
Oh yeah, another suggestion is LL_POSIX ... there's so much code
attributed to LL_LINUX, LL_DARWIN, and LL_SOLARIS that is all POSIX
compliant. An LL_POSIX macro would probably make imprudence even easier
to port since only those few non-POSIX snippits would need to be dealt
with (e.g. lldir_linux, lldir_mac, lldir_solaris, lldir_freebsd is
redundant as they all support POSIX dirent ... cp lldir_linux.*
lldir_<unix os>.*).
The llappviewerlinux is a misnomer. It seems to lack anything linux
specific.
For PLATFORM_STRING I put "Bsd" ... though Darwin is also technically
BSD, so maybe FreeBSD should be "Mac" or vice versa.
Is xmlrpc-epi.h installed in its own dedicated folder xmlrpc-epi on
Linux and Solaris? The ports system puts it in /usr/local/include and
that confused those source files that include xmlrpc-epi/xmlrpc-epi.h
Another ugly one is libpng12 ... I built it with the latest libpng, but
I had to change 3 function calls. The ports system installs headers in
/usr/local/include/libpng/*.h instead of /usr/local/include/libpng##/*.h
Best Regards,
Nathan Lay
On 06/17/11 20:44, Nathan Lay 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
More information about the ImpDev
mailing list