[impdev] Porting to FreeBSD ... and irritations

[Nathan Lay]

I'll be leaving on Friday and will not likely be able to work on this 
port for a while. I'll be sure to send whatever patches I have.  I'm 
currently porting HEAD since I thought that would be more useful 
(especially since 1.4 is apparently tremendously different).

I can't promise it will work out of the box, but it will certainly be 
something ...

I'm currently working on llqtwebkit. Another missing package in 
FreeBSD's port system is jsoncpp. Ideally llqtwebkit and jsoncpp would 
be submitted to ports. The latter is easy to port. The former ... not 
sure, I have to look at patches in the qt4 port. Might not be so easy.

llprocessor is also a bit challenging. Many of the sysctl() mibs in 
Darwin are missing in FreeBSD (e.g. cannot query L# cache size or 
available special registers, for example, with sysctl in FreeBSD).

On 06/18/11 02:08, Nathan Lay wrote:
> 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
>