We are making a lot of good progress in the realm of designing the next generation stuff. As we move forward, I've been keeping an eye on making use of as many external tools and libraries as we can to help accelerate our development cycle and hopefully improve the reliability and usability of the final product(s).

With that in mind, one thing I have been working on lately is creating a system which will allow us to make available nightly builds of our software packages. I have deployed a continuous integration server called Hudson which currently is building a copy of OpenJAUSv3.3.0c every night. I have deployed the server to the following address: http://builds.openjaus.com. In the coming weeks I'll be experimenting with this to see what all we can do. I believe we will eventually be able to automatically build our code nightly on a variety of environments (right now I am targeting i386 and ARM in linux, MinGW in Windows and the VS2005 & VS2008 compilers in Windows), build our doxygen documents, run static code evaluations, run unit tests, and even run some rudimentary valgrind tests for memory leaks and runtime issues. Check out http://builds.openjaus.com if you are interested and let me know if you have any issues (I am trying to track down why I can't access this server from some locations).

Also, I have been on the look out for other libraries we may use in the future. Today I was researching configuration files for another project at work and found a good-looking open source configuration file management utility: libconfig

That lead me to discover another interesting library on the same site: commoncpp
This seems like a really nice collection of OS abstraction classes which we should look at as we try to build the next generation codebase with a vision of more cross-platform support and usability out of the gate.

Lastly, I have been looking into using CMake on our projects. If anyone has some experience using CMake (or CTest and CDash) let me know. As I am evaluating those tools for our use as well.

Thanks!
~Danny

I used Scons before and found more useful than the regular make file. Haven't used CMake much, but an initial look at it, I still prefer it more than the old make files.

In the vein of keeping my eyes open to interesting things... Stumbled upon this today and thought maybe it would be something we might look at as a basis for some of the things we want to do with the next generation's design.

asio C++ Library

Most programs interact with the outside world in some way, whether it be via a file, a network, a serial cable, or the console. Sometimes, as is the case with networking, individual I/O operations can take a long time to complete. This poses particular challenges to application development.

Asio provides the tools to manage these long running operations, without requiring programs to use concurrency models based on threads and explicit locking.

The Asio library is intended for programmers using C++ for systems programming, where access to operating system functionality such as networking is often required. In particular, Asio addresses the following goals:

* Portability. The library should support a range of commonly used operating systems, and provide consistent behaviour across these operating systems.
* Scalability. The library should facilitate the development of network applications that scale to thousands of concurrent connections. The library implementation for each operating system should use the mechanism that best enables this scalability.
* Efficiency. The library should support techniques such as scatter-gather I/O, and allow programs to minimise data copying.
* Model concepts from established APIs, such as BSD sockets. The BSD socket API is widely implemented and understood, and is covered in much literature. Other programming languages often use a similar interface for networking APIs. As far as is reasonable, Asio should leverage existing practice.
* Ease of use. The library should provide a lower entry barrier for new users by taking a toolkit, rather than framework, approach. That is, it should try to minimise the up-front investment in time to just learning a few basic rules and guidelines. After that, a library user should only need to understand the specific functions that are being used.
* Basis for further abstraction. The library should permit the development of other libraries that provide higher levels of abstraction. For example, implementations of commonly used protocols such as HTTP.

Although Asio started life focused primarily on networking, its concepts of asynchronous I/O have been extended to include other operating system resources such as serial ports, file descriptors, and so on.

http://think-async.com/Asio/

~D