After spending a whole day, fighting with Jenkins monster it was finally able to produce the successful build.
The reasons why it fails is usually:
- out of sync package versions/configurations.
- too much dependencies in this project. (and after adding third-party libraries it’s even more now)
- lazyness (not testing before pushing the changes
But okay, lets talk about changes:
- the NativeBoost plugin, which built into VM, contains additional primitive, which was needed for callback support. This makes VMs callback-ready.
- for the first time, the Mac VM is built from scratch, bundled with Cairo graphics library. That means a new VM is ready for use by Athens with Cairo backend.
- Another important thing is encapsulating the different settings/defaults which was residing in ever-growing shell script on jenkins job into single class.
Now , to generate all sources + cmake files for building NB-enabled Cog VM, from within an image you just need to do:
and it takes care about the rest. Of course, if you may need to build custom version of VM, you will still need to deal with configurations.
Additionally, new CMakeVMMaker feature was added: generating build.sh script (which is placed in ./build subdirectory).
Actually, it could contain just two lines:
But again, on windows you will need to issue “cmake . -G”MSYS Makefiles”
, and on mac, you will need to issue “make install” after make.. So, having this script is nice addition for automated builds , where build job can just run this script and do not care about these details by itself , and for people who forgetting to do things right ;).
The recommended version of NativeBoost is 1.5 (see ConfigurationOfNativeBoost). The callback public API may take some changes (as discussed on pharo-dev mailing list), to make it convenient, but if you can’t wait, you can try it out and see if callbacks is working for you.
You can download fresh version of VMs from here:
And to install NativeBoost , you can follow instructions here:
P.S. and yes, due to problems with Windows slave, the Windows VM version is not available right now. Should be fixed soon.
Finally, i forced myself to start working on this.. it is not that i like/hate windows.. it is just different environment with different idiosyncrasies..(every has its own). And.. what i really hate is switching between working environments.
But okay, lets get to the point.. the code to use a freetype library is now:
“extra rules for Freetype plugin.
a custom rule to build freetype library”
| lib |
maker isExternal ifFalse: [
self error: 'building internal FT2Plugin is not supported yet'
“add freetype library into loop”
lib := self addThirdpartyLibrary: ‘freetype2′.
“link plugin with freetype lib”
maker addExternalLibrary: lib targetForLinking.
maker includeDirectories: lib includeDir.
Actually.. while writing this i found that “maker isExternal” are no longer relevant (at least for windows) .. I just tried to build VM with internal FT2Plugin, and it works..
addInternalPlugins: #( FT2Plugin );
Produces CogVM.exe and libfreetype-6.dll.. and it works perfectly (trust me )
So, next steps would be to integrate the changes i did on jenkins , and if people will vote for inclusion freetype support by default, we can just plug that plugin into main module body, reducing the number of files hanging around..
For changes i did, see CMakeVMMaker-IgorStasenko.175
We have a mailing list to exchange news, discuss ideas and so on.. So why we need another source of distraction (like if we don’t have too many already)?
- mails are read once, gone to trash/archive and then forgot.
- issue tracker serves a different purpose (i doubt that it would be convenient to use it as a news feed)
- documentation requires different approach and is not something on which you can spend just 2 minutes (putting a simple note)
I feel that more and more i (and i hope rest of developers) need a separate place where we can put a contextual information about VM and have it easily accessible and historically sorted and allowing others to comment.. And this is what blog does.
I don’t remember how many times i read some mail and thought “oh, this is important”.. but since i don’t have time to deal with it right now, all i do is flagging that mail.. but then as it often happens i just forget about it.. because next day there’s more and more new mails which also important.
So, i hope this blog will help up to improve our communication around VM development. But sure thing, just agreeing is not necessary, we should put an effort in it to make this work, i.e., every time we commit something, or have some experience/solved problem etc.. to not forget to go here and say about it.. this is what this blog is done for.