Note: this is not tutorial about how to compile EDE 1.x on SunStudio compiler, but impressions after compiling ede2 module (EDE 2.0).

As I wrote before, edelib and FLTK works fine with SunStudio 12 compiler. Of course, since I didn't tried edelib on this compiler for some time, some small tweaks were needed; these were mostly setting correct path to the compiler and runtime libraries (and preventing linkage with gcc libraries). Now, these steps are nicely documented in INSTALL files that comes with edelib.

So, after compiling edelib and FLTK (did I say how you must compile FLTK on SunStudio too?), EDE came. Procedure was mostly the same, except I had to hardcode fltk-config path in the configure script.

This was mandatory since configure would pick up system's fltk-config (FLTK compiled with gcc), not the one compiled with SunStudio (I placed this one in /opt/fltk-sun). This got me nice TODO to add --with-fltk-path in configure script, the same flag edelib has for these purposes.

So, before I fired jam, I disabled compiling edewm, ede-panel and efiler. edewm and ede-panel are still on eFLTK and didn't compiled eFLTK with sun's compiler. On other hand, Vedran didn't have time to update efiler on the latest edelib changes, so, generally speaking, efiler is and will be in uncompileable state for some time (I'll have to motivate him to fix this, because I don't like when repo code can't be compiled).

Compiling went fine; few small errors popped up (explicit casting to const char**, nothing serious) and a bunch of warnings, which is good :) Although I tend to compile edelib and ede with -Wall and -pedantic flags, gcc didn't complained so far.

As usually, I got a few Anachronism-istic warnings and a few vairable shadow-ings. The one was pretty interesting and I'm curious how gcc didn't catch it.

MessageBox::set_input() was implemented like this:

void MessageBox::set_input(const char* txt) {

 if(inpt)

 inpt->value(txt);

}

but MessageBox had txt as private member too. Of course, gcc was smart and got my intention, but I would much prefer some warning here. +1 for SunStudio!

Now, to save me from these from-time-to-time-remember-to-compile-with-this-or-that, I'm planning to setup buildbot with the nightly builds. Before some time, I played with CDash (via their public service), where I had to instruct edelib to generate cdash-like test result output.

I don't know what happened; few times I couldn't submit results probably because server went offline and after that, I couldn't even login to edelib CDash account (I just checked now; seems edelib is still there :)).

But, I will try to stick with the buildbot this time. CDash is CMake centric and buildbot does not need special output files to figure out were builds or tests successfull of not. There are more things to say, but since their concepts are pretty different, comparaison wouldn't be fair.