On Jan 29, 2010, at 9:01 AM, Daniel Roßberg wrote:

> 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.

That's a fantastic benefit and one of the more subtle intentions.  It  
forces us to be more aware of compatible API changes.

> 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.)

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.

> 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.

Installing the brlcad_config.h header file is not desirable or  
intentional .. but was requisite at some point because of an  
assumption we were making somewhere in the code.  I haven't gotten  
back around to checking if there is still a problem or if we can stop  
installing the config header.

Cheers!
Sean



------------------------------------------------------------------------------
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

Reply via email to