BRL-CAD

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

On Jan 31, 2010, at 1:35 PM, Gabriel M. Beddingfield wrote:

> No.  I can compile a program against Qt 4.0.0.  No matter how many  
> times I upgrade the Qt libraries (.so or .dll), my program will  
> work just fine -- without recompile -- with every Qt 4.x.x version  
> of the .so or .dll.
>
> Qt is not unique.  Most libraries work this way to some extent.

Qt isn't unique in that regard but the compatibility also does not  
happen automatically.  They go to great lengths to make sure they are  
API and ABI compatible as it's their bread and butter.  They have  
plenty of paying customers that have that requirement.

If we do our job correctly, we aim for similar compatibility on our  
minor version numbers (e.g., 7.16.x are all compatible).  Without a  
comprehensive test suite, though, that compatibility cannot be  
assured with a high degree of confidence.  It requires manual effort  
and ongoing diligence.

It actually doesn't take much at all to break ABI compatibility where  
a recompile becomes required, particularly if there is C++ in the API..

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)

Cheers!
Sean

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.

> I had a different impression:  "Unfortunately, this convention [i.e.
> release numbers encoded in the library names] conflicts directly with
> libtool's idea of library interface versions, ..." (from the libtool
> manual)  Then they write something about libtool's -release flag.
>
> However, from the manual I have an idea how it could work: The version
> information is part of the .la-file in liked this way into the
> executable (which uses this information e.g. for its library search
> method during loading).  Right?

Sort of.  Libtool uses the version compatibility information  
differently for different platforms.  For Mac OS X, for example,  
dylibs actually have an encoded concept of their current version and  
compatibility versions.  So a binary can search at the point of  
invocation for compatible libraries that meet its requirements.  If I  
recall correctly, GNU BFD libraries have a very similar concept that  
the GNU linker can take advantage of.

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.

Cheers!
Sean

2010/2/19 Christopher Sean Morrison <brlcad@...>:
>
> 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

On Feb 26, 2010, at 10:41 AM, Daniel Roßberg wrote:

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

That is a very good point.  Exposing an integer version functions or  
global is only a variation of what is currently provided.  
Technically, the intent of the brlcad_version() function and  
bu_version(), bn_version(), etc, functions are to provide the  
version, just that they only provide it in string form (so you have  
to parse the numbers out).  That was only done just to mirror the  
previous version string that was used to get embedded from  
autogenerated vers.c files.

I have no problems exposing integer functions or globals, but which  
problem is that solving?  It certainly doesn't solve Tom's issue, and  
it only solves your issue with detecting if a runtime library matches  
if it's a static.   My preference would be a function returning the  
library version numbers (as ints, not strings), but that would merely  
a more convenient form of bu_version() and friends.

> But, to be honest, I find it remarkable that so many other software
> projects provide their version information via defines.

It's definitely the "easy" thing to do.

> What should the brlcad-config script do?

*-config scripts report compilation information for a given install.   
They are pretty common across open source packages as the means to  
look up information on that install including libraries, version  
information, compilation flags, linker flags, features enabled/ 
disabled, etc.  You probably have several dozen installed (on Linux)  
already.  Some common ones:  cups-config, curl-config, php-config,  
xml2-config, python-config, apr-config, ...

The script does provide the information that would solve Tom's  
issue.  Not necessarily in a "pretty" way, but it would do the trick  
in giving him version information to key off of:

sushi:~ morrison$ echo "-DCAD_VERSION=`printf "%02d%02d%02d" \`sh  
brlcad/misc/brlcad-config --version | sed 's/\./ /g'\``"
-DCAD_VERSION=071607

In code, you would then:

#if defined(CAD_VERISON) && CAD_VERSION < 071600
.. do the old thing ..
#else
.. do the new thing ..
#endif

The idea would be to make brlcad-config be more portable (make it  
work on windows) and use it within the build environment similar to  
what you're doing within CMakeLists.txt to get the date and time,  
similar to running what is shown above in a configure script or  
Makefile, similar to running a VBScript within MSVC.

If it wasn't originally clear, this brlcad-config script already  
exists and is installed for *nix systems.  It's in the misc/  
directory.  The "problem" is that it's presently a shell script, but  
could easily be made up into a compiled program or a batch script.

Cheers!
Sean

Sean, all

Glad to be here, then!  I'd be more than happy to do some work on the
website, though I'd like to know who is in charge of it, of course.

The round-trip documentation interface does sound interesting.  More detail
would certainly be welcome.

-Matthew

On Thu, Feb 18, 2010 at 6:00 AM, Sean Morrison <brlcad@...
> wrote:

>
> Message body follows:
>
> Matthew,
>
> With a system as large and complex as BRL-CAD, there are ways just
> about anyone can contribute in very effective ways.  That said, you
> seemingly understate your capacity to do something useful from the
> look of the skills you list.
>
> I'd recommend getting started on something that leverages your
> current skills, as there will be plenty about BRL-CAD that will take
> a while to get familiarized with no matter what you work on.  From
> what you list, this is perhaps something related to website
> development.
>
> Our website has much room for improvement, obviously, so there is
> plenty you can work on from basic aesthetic redesign to a specific
> programming project.  One programming project that comes to mind
> that
> would have a big impact is working on a round-trip documentation
> interface.  If that sounds interesting, I can go into more detail.
> That said, there are plenty of other ideas that come to mind as well.
>
> Feel free to join the brlcad-devel developer's mailing list and/or
> our IRC channel.
>
> Cheers!
> Sean
>
> cc brlcad-devel
>
> --
> This message has been sent to you, a registered SourceForge.net user,
> by another site user, through the SourceForge.net site.  This message
> has been delivered to your SourceForge.net mail alias.  You may reply
> to this message using the "Reply" feature of your email client, or
> using the messaging facility of SourceForge.net at:
> https://sourceforge.net/sendmessage.php?touser=785737
>
>

Matthew,

All of BRL-CAD development, including the website, is developed under  
a meritocracy.  Basically we all work on various things that are of  
interest and come to consensus agreement unless there is a specific  
issue requiring intervention.  Those who constructively contribute,  
frequently interact, and remain highly involved have more say than  
those who do not.  This generally empowers contributors to work  
towards the best interests of the project unhindered as long as  
they're persistently and openly communicating with others WHILE they  
work (not just when they're "done" with something).

So, to answer your question, everyone who has contributed more than  
you is "in charge" but things don't work that way in practice.  If  
someone steps up to work on a project, nobody is generally going to  
stop them unless the project is outside of scope, affects usability,  
will be a maintenance burden, or changes a public interface.

Working on a round-trip documentation interface is something that  
we've been working towards for several years, but the goal is a bit  
tricky.  We want the power of revision-controlled documents checked  
into a repository with the accessibility of a wiki, and the ability  
to edit on either end.

Getting our documentation into a structured format -- Doxbook/XML --  
has provided tracking, integration, and validation of our  
documentation with easy export to a variety of formats.  Several  
contributors have been working on converting our existing  
documentation (which is in a myriad of formats).  This has been going  
great for some ... but writing XML, getting access and committing to  
an SVN repository, and setting up an XML toolchain is not exactly  
what I'd call "accessible".

The idea is to provide some mechanism that allows our documentation  
to get published/presented to the web, but in an editable format.  As  
our web infrastructure is built on Mediawiki and Drupal, the natural  
direction becomes a plugin in either one of those systems.  The hard  
part is then how to manage "editing fragments" that compose various  
larger works and the conversion to/from Docbook if an alternate  
format is presented (e.g., wikitext markup).

Even if the web-editing user were presented with the raw Docbook/XML  
(instead of wikitext) but could then see validation errors and/or see  
their result rendered on-line, we would have a very useful round-trip  
online editing capability.  Developers would be able to edit the  
Docbook directly in the repository and push changes to the website.   
External web users would be able to see our documentation, make minor  
edits quickly (even anonymously), and have those changes persist to  
the repository.

Cheers!
Sean



On Feb 18, 2010, at 9:33 AM, Matthew Ayres wrote:

> Sean, all
>
> Glad to be here, then!  I'd be more than happy to do some work on  
> the website, though I'd like to know who is in charge of it, of  
> course.
>
> The round-trip documentation interface does sound interesting.   
> More detail would certainly be welcome.
>
> -Matthew
>
> On Thu, Feb 18, 2010 at 6:00 AM, Sean Morrison  
> <brlcad@...> wrote:
>
> Message body follows:
>
> Matthew,
>
> With a system as large and complex as BRL-CAD, there are ways just
> about anyone can contribute in very effective ways.  That said, you
> seemingly understate your capacity to do something useful from the
> look of the skills you list.
>
> I'd recommend getting started on something that leverages your
> current skills, as there will be plenty about BRL-CAD that will take
> a while to get familiarized with no matter what you work on.  From
> what you list, this is perhaps something related to website
> development.
>
> Our website has much room for improvement, obviously, so there is
> plenty you can work on from basic aesthetic redesign to a specific
> programming project.  One programming project that comes to mind
> that
> would have a big impact is working on a round-trip documentation
> interface.  If that sounds interesting, I can go into more detail.
> That said, there are plenty of other ideas that come to mind as well.
>
> Feel free to join the brlcad-devel developer's mailing list and/or
> our IRC channel.
>
> Cheers!
> Sean
>
> cc brlcad-devel
>
> --
> This message has been sent to you, a registered SourceForge.net user,
> by another site user, through the SourceForge.net site.  This message
> has been delivered to your SourceForge.net mail alias.  You may reply
> to this message using the "Reply" feature of your email client, or
> using the messaging facility of SourceForge.net at:
> https://sourceforge.net/sendmessage.php?touser=785737
>
>
> ---------------------------------------------------------------------- 
> --------
> Download Intel&reg; 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
> brlcad-devel@...
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Excellent, I do like to see a meritocratic approach.  It sounds like it
works well here, too.

I think I can see ways for the round-trip interface to work.  My initial
reaction is bi-directional parsing, to rebuild the formatting of any change
so that it can be slotted in/over as appropriately at the other end.
Obviously I'll have to look at how it's working, though.

Sounds like a fun project actually.

On Thu, Feb 18, 2010 at 10:23 PM, Christopher Sean Morrison
<brlcad@...:

>
> Matthew,
>
> All of BRL-CAD development, including the website, is developed under a
> meritocracy.  Basically we all work on various things that are of interest
> and come to consensus agreement unless there is a specific issue requiring
> intervention.  Those who constructively contribute, frequently interact, and
> remain highly involved have more say than those who do not.  This generally
> empowers contributors to work towards the best interests of the project
> unhindered as long as they're persistently and openly communicating with
> others WHILE they work (not just when they're "done" with something).
>
> So, to answer your question, everyone who has contributed more than you is
> "in charge" but things don't work that way in practice.  If someone steps up
> to work on a project, nobody is generally going to stop them unless the
> project is outside of scope, affects usability, will be a maintenance
> burden, or changes a public interface.
>
> Working on a round-trip documentation interface is something that we've
> been working towards for several years, but the goal is a bit tricky.  We
> want the power of revision-controlled documents checked into a repository
> with the accessibility of a wiki, and the ability to edit on either end.
>
> Getting our documentation into a structured format -- Doxbook/XML -- has
> provided tracking, integration, and validation of our documentation with
> easy export to a variety of formats.  Several contributors have been working
> on converting our existing documentation (which is in a myriad of formats).
>  This has been going great for some ... but writing XML, getting access and
> committing to an SVN repository, and setting up an XML toolchain is not
> exactly what I'd call "accessible".
>
> The idea is to provide some mechanism that allows our documentation to get
> published/presented to the web, but in an editable format.  As our web
> infrastructure is built on Mediawiki and Drupal, the natural direction
> becomes a plugin in either one of those systems.  The hard part is then how
> to manage "editing fragments" that compose various larger works and the
> conversion to/from Docbook if an alternate format is presented (e.g.,
> wikitext markup).
>
> Even if the web-editing user were presented with the raw Docbook/XML
> (instead of wikitext) but could then see validation errors and/or see their
> result rendered on-line, we would have a very useful round-trip online
> editing capability.  Developers would be able to edit the Docbook directly
> in the repository and push changes to the website.  External web users would
> be able to see our documentation, make minor edits quickly (even
> anonymously), and have those changes persist to the repository.
>
> Cheers!
> Sean
>
>
>
> On Feb 18, 2010, at 9:33 AM, Matthew Ayres wrote:
>
> Sean, all
>
> Glad to be here, then!  I'd be more than happy to do some work on the
> website, though I'd like to know who is in charge of it, of course.
>
> The round-trip documentation interface does sound interesting.  More detail
> would certainly be welcome.
>
> -Matthew
>
> On Thu, Feb 18, 2010 at 6:00 AM, Sean Morrison <
> brlcad@...> wrote:
>
>>
>> Message body follows:
>>
>> Matthew,
>>
>> With a system as large and complex as BRL-CAD, there are ways just
>> about anyone can contribute in very effective ways.  That said, you
>> seemingly understate your capacity to do something useful from the
>> look of the skills you list.
>>
>> I'd recommend getting started on something that leverages your
>> current skills, as there will be plenty about BRL-CAD that will take
>> a while to get familiarized with no matter what you work on.  From
>> what you list, this is perhaps something related to website
>> development.
>>
>> Our website has much room for improvement, obviously, so there is
>> plenty you can work on from basic aesthetic redesign to a specific
>> programming project.  One programming project that comes to mind
>> that
>> would have a big impact is working on a round-trip documentation
>> interface.  If that sounds interesting, I can go into more detail.
>> That said, there are plenty of other ideas that come to mind as well.
>>
>> Feel free to join the brlcad-devel developer's mailing list and/or
>> our IRC channel.
>>
>> Cheers!
>> Sean
>>
>> cc brlcad-devel
>>
>> --
>> This message has been sent to you, a registered SourceForge.net user,
>> by another site user, through the SourceForge.net site.  This message
>> has been delivered to your SourceForge.net mail alias.  You may reply
>> to this message using the "Reply" feature of your email client, or
>> using the messaging facility of SourceForge.net at:
>> https://sourceforge.net/sendmessage.php?touser=785737
>>
>>
>
> ------------------------------------------------------------------------------
> Download Intel&reg; 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
> brlcad-devel@...
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
> brlcad-devel@...
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>

On Thu, Feb 18, 2010 at 08:28, Matthew Ayres
<solar.granulation@...> wrote:
> Tom,
>
> Have you considered writing a patch?  It ought to be possible to issue a
> patch, along with your code, that would add a default value for *resp.  Of

I could do that, but I don't think that would be in the spirit of the
changed API.  I would rather work on a patch to make the version
macro--but I don't think Sean is convinced of its utility.

> Still, wouldn't it make more sense for one of you to change his version to
> match that which the other is using?

Yes, but it probably won't happen for a while--don't ask!

Thanks, Matthew.

Regards,

-Tom

Tom,

Minor API changes such as the one you encountered should be expected  
across minor revision numbers (7.12 vs 7.14).  The doc/ 
deprecation.txt file describes changes that are considered "minimally  
impacting" as:

"Minimally Impacting: If a change to an interface has a suitable and  
completely equivalent alternative, the change is deemed to be  
"minimally impacting" and can be made during any minor release.  
Examples of such changes include renaming an interface, reordering  
parameters, adding new parameters to an interface for previously  
implicit or restricted behavior, and removing unused parameters.  
Basically, the impact can usually be considered minor if a simple  
regular expression search-and-replace is all that is needed."

The intention is to avoid stagnating the API, so that it may be  
adaptively evolved and improved.  Maintaining API portability is of  
course of paramount concern, but the APIs (of all of our libraries)  
have lots of room for improvement, inconsistencies, poor naming  
choices, and more.  So when there's a change, such as the unused  
resource pointer on rt_db_free_internal(), the deprecation process  
allows it to be fixed during a minor release.

Version numbers were specifically hidden from headers to prevent  
developers from making compile-time affordances in code for multiple  
versions of API.  Exactly what it sounds like you're trying to do to  
work around the signature change.. :)  Those "#if version ==  
whatever" compile-time checks are certainly convenient and simple but  
they slow down API evolution detrimentally and cause added migration  
burdens for all involved down the road.

Is this a case of looking for a technical solution to a sociological  
problem?  If you're collaborating with someone on a bit of code, it  
sounds like you both should be on the same version (at least the same  
minor version).  What is keeping your teammate from upgrading?  Or  
why are you using the latest release instead of the version they're  
using?

That said, if I were in your situation and HAD to figure something  
out and they could not upgrade, then my solution would probably be to  
manually keep a sed script on hand that converts the code to the new  
version on my end.  All of the minimally impacting changes should be  
converted with a simple regular expression (the regex for the  
rt_db_free_internal() change is in doc/deprecation.txt).  If that was  
too much of a burden, I could always wrap the latest code in some  
arbitrary define that I pass as a CPPFLAG when I build.

Cheers!
Sean


On Feb 1, 2010, at 4:45 PM, Tom Browder wrote:

> I am now running into a situation where my development system is using
> the latest release of BRL-CAD (7.16.4) and my remote team mate is
> using an older one (7.12.6) and some function signatures have changed.
>  Specifically,
>
>    void rt_db_free_internal(struct rt_db_internal *ip, struct  
> resource *resp);
>
> became
>
>   void rt_db_free_internal(struct rt_db_internal *ip);
>
> and g++ 4.4.3 doesn't like that.  I have found no clean way to use a
> compile-time cpp macro to distinguish the two versions but would
> appreciate any ideas.  I know my team mate needs to upgrade, but that
> isn't in the cards at the moment.
>
> Note there is a PACKAGE_VERSION defined as a string but I don't think
> you can use that at compile time (at least I haven't found a solution
> looking at the cpp manual).
>
> I think we need something like gcc and others use:
>
>   #define BRLCAD_MAJOR_VERSION 7
>   #define BRLCAD_MINOR_VERSION 16
>   #define BRLCAD_PATCH_VERSION 4
>
>> From the cpp manual (4.4.3), gcc defines three macros
>
>   __GNUC__                           // major version
>   __GNUC_MINOR__
>   __GNUC_PATCHLEVEL__
>
> and they show a couple of ways to test for a specific version.  I like
> this method:
>
>   #define GCC_VERSION (__GNUC__ * 10000 \
>                                        + __GNUC_MINOR__ * 100 \
>                                       + __GNUC_PATCHLEVEL__)
>
>   /* Test for GCC > 3.2.0 */
>   #if GCC_VERSION > 30200
>
> or BRl-CAD could just take the easier, direct route:
>
>   #define BRLCAD_VERSION    71604    // allows up to 100 minor
> versions and 100 patch levels for each major version
>
> For the moment I will use a kludge macro until I hear the magic  
> solution.
>
> Thanks.
>
> -Tom
>
> Thomas M. Browder, Jr.
> Niceville, Florida
> USA
>
> ---------------------------------------------------------------------- 
> --------
> 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
> brlcad-devel@...
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel

On Sun, Feb 14, 2010 at 00:26, Christopher Sean Morrison <brlcad@...> wrote:
> Minor API changes such as the one you encountered should be expected across

Sean, I'm not complaining about the API change (just was a little surprised).

> Version numbers were specifically hidden from headers to prevent developers
> from making compile-time affordances in code for multiple versions of API.

How does that hinder anyone who doesn't want to be hindered?

>  Exactly what it sounds like you're trying to do to work around the
> signature change.. :)  Those "#if version == whatever" compile-time checks
> are certainly convenient and simple but they slow down API evolution
> detrimentally and cause added migration burdens for all involved down the

Do you mean BRL-CAD developers?  If so, how would it bother them if
BRL-CAD itself didn't use the information?  Isn't providing a version
macro something that could be automated since you give each release a
version?

> Is this a case of looking for a technical solution to a sociological
> problem?  If you're collaborating with someone on a bit of code, it sounds
> like you both should be on the same version (at least the same minor
> version).  What is keeping your teammate from upgrading?  Or why are you

The problem is that the other part of the team is doing development
with Windows and they have had problems in the past with BRL-CAD on
Windows and are not as willing to update or install from source as us
*nix people are.

> doc/deprecation.txt).  If that was too much of a burden, I could always wrap
> the latest code in some arbitrary define that I pass as a CPPFLAG when I
> build.

That's what I've done, but it would be more convenient if there were a
version macro I could count on.

Thanks, Sean.

Regards,

-Tom

On Feb 14, 2010, at 5:27 AM, Tom Browder wrote:

>> Version numbers were specifically hidden from headers to prevent  
>> developers
>> from making compile-time affordances in code for multiple versions  
>> of API.
>
> How does that hinder anyone who doesn't want to be hindered?

In a way, it hinders the API developers.  In my experience, it causes  
old interfaces to hang around much longer than is desired and  
increases support maintenance.  Those are two subtle points, and not  
a "major" issue for either, but they're a burden that I would prefer  
to avoid entirely if we can.  Especially when the need is driven by a  
non-technical requirement, a non-technical solution is often better.   
Basically, it's preferring to let the API evolve in a controlled  
fashion letting external developers not have to maintain multiple  
interfaces either -- the code works with a given minor revision or  
you're following a branch (like trunk).

>> Exactly what it sounds like you're trying to do to work around the
>> signature change.. :)  Those "#if version == whatever" compile- 
>> time checks
>> are certainly convenient and simple but they slow down API evolution
>> detrimentally and cause added migration burdens for all involved  
>> down the
>
> Do you mean BRL-CAD developers?  If so, how would it bother them if
> BRL-CAD itself didn't use the information?  Isn't providing a version
> macro something that could be automated since you give each release a
> version?

I meant "external developers" and external codes that make calls into  
the BRL-CAD APIs.  The burden on their end is increased code entropy  
to maintain (multiple versions #ifdef'd), which isn't necessarily our  
direct concern, but a burden we'd be allowing others to take upon  
themselves.  That by itself is a minor point but then there is also a  
burden for BRL-CAD developers of having to sort through development  
issues with old API generally longer than usual and in potentially  
inconsistent manners.  Old API code is allowed to linger and worse  
yet, can unknowingly get intermingled with new API code causing  
difficult bugs.

> The problem is that the other part of the team is doing development
> with Windows and they have had problems in the past with BRL-CAD on
> Windows and are not as willing to update or install from source as us
> *nix people are.

That sounds like an area we should be investing effort if it's  
problems with a current version.  Have they repeatedly had problems  
on Windows *after* doing an update (beyond minor edits to support new  
API, such as the rt_db_free_internal())?  Or just general  problems  
in the past getting things to work?  Or are they just resistant to  
change?

If they're like other developers I know where BRL-CAD is a tertiary  
concern, once things work they don't really want to change anything  
unless they absolutely have to.  The disconnect is that you do,  
wanting to follow the latest development.  Ideally, you'd both follow  
the latest development.

Again, this isn't a show-stopper if we had to make the version  
available as compile-time definitions, but I'd prefer it be for some  
technical benefit.  In clarifying the reasons through these  
discussions, I do realize many of the points are presumptuous (and  
don't mean to be) -- it's more trying to encourage even our external  
developers to become/be more adaptive so we can evolve and improve  
faster, avoiding stagnation and complacency because things seem to  
"work".

Cheers!
Sean

Please pardon my noise--not paying attention.

-Tom

Sinclair,

We investigated this issue a few days ago and it turns out there's a  
bug in GCC.  More specifically, it's a bug in the STL headers that  
gcc provides.  We've applied a work-around fix that will be in a  
future release, but the problem should be reported upstream to the  
gcc folks (please feel free to do so).

The fix is pretty simple to apply directly yourself.  The fix should  
proceed if you edit src/other/openNURBS/opennurbs_system.h and add  
the following line around line 197:

#include <stddef.h>

Cheers!
Sean


On Feb 8, 2010, at 10:19 AM, NITA BUDD wrote:

> Hello
>   While trying to compile  7.16.4 on a Suse 11.1 system the error  
> messages, shown below,  occur.
> I have been able to compile the openNURBS library as a stand-a- 
> lone  compilation from the source code on the http://www.opennurbs.org   
> web site.
>
>
> Please ask for any further diagnostics if that would be helpful.
>
> Regards
> Sinclair
>
>
> Short error messages
> ----------------------
> Making all in openNURBS
> make[3]: Entering directory `/extra/brlcad-7.16.4/src/other/openNURBS'
> /bin/sh .../../../libtool --silent --tag=CXX --mode=compile g++ - 
> DHAVE_CONFIG_H -I. -I. -I../../../include   -I/usr/local/include - 
> DBRLCADBUILD=1 -I../../../include -I../../../src/other/openNURBS  - 
> Wall  -pipe -fno-strict-aliasing -fno-common -fexceptions -g -c -o  
> libopenNURBS_nil_la-opennurbs_3dm_attributes.lo `test -f  
> 'opennurbs_3dm_attributes.cpp' || echo  
> './'`opennurbs_3dm_attributes.cpp
> In file included from /usr/include/c++/4.3/new:44,
>                  from opennurbs_system.h:247,
>                  from opennurbs.h:28,
>                  from opennurbs_3dm_attributes.cpp:16:
> /usr/include/c++/4.3/cstddef:55: error: '::ptrdiff_t' has not been  
> declared
> make[3]: *** [libopenNURBS_nil_la-opennurbs_3dm_attributes.lo] Error 1
> make[3]: Leaving directory `/extra/brlcad-7.16.4/src/other/openNURBS'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/extra/brlcad-7.16.4/src/other'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/extra/brlcad-7.16.4/src'
> make: *** [all-recursive] Error 1
> nita@...>
>
>
>
>
> Long error messages
> -----------------------
> Making all in openNURBS
> make[3]: Entering directory `/extra/brlcad-7.16.4/src/other/openNURBS'
> /bin/sh ../../../libtool --tag=CXX --mode=compile g++ - 
> DHAVE_CONFIG_H -I. -I. -I../../../include   -I/usr/local/include - 
> DBRLCADBUILD=1 -I../../../include -I../../../src/other/openNURBS - 
> I../../../src/other/libz -Wall -I../../../src/other/libz -pipe -fno- 
> strict-aliasing -fno-common -fexceptions -g -W -Wall -Wundef - 
> Wfloat-equal -Wshadow -Winline -c -o libopenNURBS_nil_la- 
> opennurbs_3dm_attributes.lo `test -f 'opennurbs_3dm_attributes.cpp'  
> || echo './'`opennurbs_3dm_attributes..cpp
>  g++ -DHAVE_CONFIG_H -I. -I. -I../../../include -I/usr/local/ 
> include -DBRLCADBUILD=1 -I../../../include -I../../../src/other/ 
> openNURBS -I../.../../src/other/libz -Wall -I../../../src/other/ 
> libz -pipe -fno-strict-aliasing -fno-common -fexceptions -g -W - 
> Wall -Wundef -Wfloat-equal -Wshadow -Winline -c  
> opennurbs_3dm_attributes.cpp  -fPIC -DPIC -o .libs/ 
> libopenNURBS_nil_la-opennurbs_3dm_attributes.o
> In file included from /usr/include/c++/4.3/new:44,
>                  from opennurbs_system.h:247,
>                  from opennurbs.h:28,
>                  from opennurbs_3dm_attributes.cpp:16:
> /usr/include/c++/4.3/cstddef:55: error: '::ptrdiff_t' has not been  
> declared
> In file included from opennurbs.h:42,
>                  from opennurbs_3dm_attributes.cpp:16:
> opennurbs_base64.h:130: warning: type qualifiers ignored on  
> function return type
> In file included from opennurbs.h:93,
>                  from opennurbs_3dm_attributes.cpp:16:
> opennurbs_light.h:115: warning: type qualifiers ignored on function  
> return type
> opennurbs_light.h:116: warning: type qualifiers ignored on function  
> return type
> opennurbs_light.h:117: warning: type qualifiers ignored on function  
> return type
> opennurbs_light.h:118: warning: type qualifiers ignored on function  
> return type
> opennurbs_light.h:119: warning: type qualifiers ignored on function  
> return type
> opennurbs_3dm_attributes.cpp: In member function 'bool  
> ON_3dmObjectAttributes::operator==(const ON_3dmObjectAttributes&)  
> const':
> opennurbs_3dm_attributes.cpp:91: warning: comparing floating point  
> with == or != is unsafe
> opennurbs_3dm_attributes.cpp: In member function 'virtual ON_BOOL32  
> ON_3dmObjectAttributes::Read(ON_BinaryArchive&)':
> opennurbs_3dm_attributes.cpp:477: warning: declaration of 'i'  
> shadows a previous local
> opennurbs_3dm_attributes.cpp:387: warning: shadowed declaration is  
> here
> opennurbs_3dm_attributes.cpp: In member function 'bool  
> ON_3dmObjectAttributes::WriteV5Helper(ON_BinaryArchive&) const':
> opennurbs_3dm_attributes.cpp:598: warning: comparing floating point  
> with == or != is unsafe
> make[3]: *** [libopenNURBS_nil_la-opennurbs_3dm_attributes.lo] Error 1
> make[3]: Leaving directory `/extra/brlcad-7.16.4/src/other/openNURBS'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/extra/brlcad-7.16.4/src/other'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/extra/brlcad-7.16.4/src'
> make: *** [all-recursive] Error 1
> nita@...>
>
>
>
>
>
>
> ---------------------------------------------------------------------- 
> --------
> 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
> brlcad-devel@...
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel