Well,
let me try to explain my concern more precisely. I'm programming
closed source software using the BRL-CAD core libraries. And because
of the LGPL I'm using the BRL-CAD code via a dynamically linkable
library. However, it turned out that it is very favorable to have it
in a DLL because this way I can update our old programs too (e.g. they
can use newly introduced primitives) without touching our own
binaries.
But this isn't only a matter of closed source programs. E.g. on Linux
installations you have basic installations of Python, TCL etc. and
many programs using these. And there is my point: The programs
memorized the Python, TCL, etc. library version they were build with.
For example you may use the package manager of your choice an look at
the dependencies section there. This section won't ask the installed
Python, TCL etc. for its version but a manifest file belonging to the
program.
Now I want to do something similar with BRL-CAD. How do I get the
dependency/compatibility numbers for my manifest file? (I don't
really have a manifest file but something similar.)
BTW, this is a problem on MS Windows only. "make install" copies the
brlcad_config.h too which contains the PACKAGE_STRING and
PACKAGE_VERSION defines.
If we could agree that there is a point we could look for an optimal solution.
Sziasztok,
Daniel
2010/1/21 Christopher Sean Morrison <[email protected]>:
>
>
> Delayed response but I put some more thought into this problem recently...
>
>
> On Tuesday, July 14, 2009, at 09:24AM, "Daniel Roßberg"
> <[email protected]> wrote:
>>Hi,
>>
>>There were put a lot of effort into hiding any version number define
>>and/or constant from the user. Now I'm in doubt if this was wise.
>
> The core issue I'm concerned with is making it difficult for version-specific
> compile-time code to be written. If we can find a run-time solution, that
> should be fine.
I'm afraid run-time is too late. I want to memorize what happened
before somebody copied his brlcad.dll into my program directory. I.e.
which was the original BRL-CAD version the program was build with?
>>I ran into the problem that the BRL-CAD version present at link time
>>is another than at run time. I.e. I upgrade the BRL-CAD library by
>>replacing the brlcad.dll and keeping the program executable. This may
>>lead to compatibility problems. To deal with this kind of problems it
>>would be good to have the possibility to memorize the BRL-CAD version
>>at build time in the executable.
>
> "Our" executables already have the ability to be aware of the BRL-CAD version
> they are part of via the brlcad_version() and brlcad_ident() functions.
> Given they are static, they will get compiled into whatever front-end binary
> or back-end DLL that calls them (which is of course intentional).
>
> Each library has a LIB_version() function which could be compared against the
> library versions to determine compatibility. Granted, the version functions
> presently return strings, but that could be separated from the number itself
> similar to brlcad_version()/brlcad_ident() for each library.
Compare what against what? librt_version() against libbn_version()?
According to your requirements it is not possible to compile something
like an original version into my program I could use for comparison.
>>Is there already a practicable solution for this problem based on an
>>installed BRL-CAD?
>
> Yeah.. the issue then remaining is that brlcad_version.h is not presently
> installed and the geometry engine (coreInterface, GE, and GS included) are
> written as if they were some 3rd-party developer using the public API. The
> solutions that immediately come to mind are:
>
> a) Install brlcad_version.h (along with include/conf) making it similar to
> common.h (i.e. not owned by any library except libbrlcad). I'd want to undef
> the version variables so they're not compile-time accessible. We could also
> install brlcad_version.h without include/conf, but Windows becomes a little
> problematic.
>
> b) Treat the engine like other BRL-CAD code, requiring a 'brlcad' source tree
> so it can get at brlcad_version.h. The downside of this is of course the
> benefits of API separation and loosely coupled development. The benefit
> would be simplified build integration and access to private API.
>
>
>>At the moment I'm creating my "private" brlcadversion.h to be
>>distributed with the brlcad.dll developer package.
>
> Does this include the include/conf files, or do you just create your own
> header with the values you need?
I created my own header.
> Cheers!
> Sean
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> BRL-CAD Developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
