[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