2010/2/19 Christopher Sean Morrison <[email protected]>:
>
> On Feb 1, 2010, at 12:52 PM, Daniel Roßberg wrote:
>
>> I'm afraid this discussion is losing the common interest. I.e. we
>> could continue it by private mail or IRC (if I'm logged in ;-}.
>
> What a horrible suggestion to take the discussion private! :-)
> Developer discussions should be public. Even the lurkers read.
> Shared knowledge is common knowledge.
OK. Therefore I'll continue to make some noise here ;-)
> Interestingly enough, the approach on *nix as we're currently set up
> is to utilize brlcad-config or pkg-config as they report manifest,
> linkage, and version information. That naturally doesn't help you on
> Windows without a posix shell, but may be a similar approach that
> could be set up that would avoid header versioning. A variation on
> make.vbs would probably do the trick to generate a brlcad-config.vbs
> that provides version and linkage information.
I don't use include/conf/make.vbs any more since I changed to CMake.
See e.g. include/conf/CMakeLists.txt for how I generate the COUNT,
DATE etc. files.
In misc/win32-msvc/Dll/CMakeLists.txt I generate a header file with
version information (brlcadversion.h). But for this file I'm using
"bad" defines. Although I could live with >const int< too. This type
can't be used for conditional compilations.
But, to be honest, I find it remarkable that so many other software
projects provide their version information via defines.
> The point still stands for a binary being at least aware of what it
> was compiled with, which we already do for our internal codes. The
> issue from my perspective is how to best enable that capability for
> external codes with or without exposing header version defines.
> Would a run-time brlcad-config application/script/whatever be
> sufficient? (Particularly relevant to your needs too, Tom)
What should the brlcad-config script do?
Or the other way round: Look at the brlcad-~_win32-dll_devel packages.
We are using here exactly these packages for our own software. (They
correspond kinda with a BRL-CAD installation. BTW, as mentioned
before they contain the brlcadversion.h header with the defines
requested by Tom ;) Should these packages contain a brlcad-config
scrip? What should such a script do?
> The information is definitely included in the libtool archive
> (the .la file), but that's only useful at link time and for libtool
> projects.
>
> Interesting food for thought, but it would be more beneficial to find
> a platform-agnostic solution, or at least a solution that is nearly
> identical across platforms.
A MS Windows DLL contains the version information too (if it was
included during linking). But the linking of the executable happens
without touching the DLL. In general a .lib file is used which
doesn't contain the version information. To be platform independent
we would probably need a distinct file with this information.
Sziasztok,
Daniel
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
