My company, after months of recommendation, finally got to buy Neutrino 6.3 for our future projects.
My experience with QNX dates back to QNX4 so I’m a bite overwhelmed with the Momentics way of doing things. We are using QNX C++ project makefile.
We are about to built several shared libraries that will surely evolve as time goes by so I want to take advantage of Momentics versioning feature to ease the management of the various libraries versions.
I managed to build a test shared library and to use it with a test application. I saw, by using ldd on the application, that the library version number stored in the library is changing as I am changing the “library versionâ€
[quote]
This brings me to my silly question. What do you have to do in Momentics to change the output library file name so that it will come up as “filename.so.versionâ€
I finally found the way to achieve what I wanted. My special thanks to Albrecht for its input it really gave me a push in the right direction.
I must admit that I’m usually not a big fan of GUIs when it comes to creating Makefiles but it seems QNX peoples really did a great job with Momentics. All the variables describe in the “Conventions for Makefiles and Directories” document have their equivalent in the Momentics IDE.
Are you OK with manually updating the library version number?
How important would an automatic analysis of the exports from the library, that automatically incremented the version number whenever a change in interface was detected, be to you? (this is just one of my personal peeves, I have no idea if anyone is planning on implementing such a thing).
btw: if you like what you’ve encountered so far, wait until you use the system profiler to find some gnarly bug in your application!
I don’t know. Playing around with library versions, from my point of view, is only a last resource in resolving a compatibility issue, it should not be used as a design tool. As such, I think there are other things in the IDE that should be looked upon, i.e. the incredibly slow and not customizable source indexer, the fact that a source tree created with IDE is not 100% compatible with the one created by addvariant and vice versa, to name a few.
The IDE is really good and it is becoming better with each version, but the areas of improvement are elsewhere.
Other curious question: Is it possible, within the system profiler, to overlay a particular message with a C data structure to see what is actually in it? At least the predefined structures (e.g. _IO_WRITE etc) should be known.
I don’t’ believe that automatically incrementing the version number would be really practical. I think that the manual handling is the way to go because a new version number, from my point of view, should be used when a new release of the library is performed, not when its files are modified.
What I mean is that you might have to modify library files several times in order to add new functionalities or to fix bugs. You should increase the version number only when those modifications have been tested successfully so that in can be synchronize with your software version control systems and the new library package.
No, the idea is that it would interrogate the exports in the resulting .os, and detect a change in the API interface. You could change the library all you want and as long as you didn’t touch the interface the version number would not increment. When you changed the API (and built the lib and installed) it, the version number would automatically increment.
You absolutely want a new version number whenever the interface changes.
