On Jan 6, 2011, at 5:12 PM, Clifford Yapp wrote:

> It's used in both the test iges converter and the step-g converter.
> The latter isn't yet being built on Windows, but the former needs it.
> I can just turn it off for now - it's not installed.

Since your follow-up said step-g was doing it's own thing, it sounds  
like the encapsulation breakage is pretty limited then.  Does the  
n_iges converter actualy "need" to pull curves back?  If it does,  
then the routine should be made into a proper librt API function  
(e.g., rt_pullback_curve()) or a new extended openNURBS library  
(libExON? libONE? libOpenNURBSEx?).

A quick review shows a related problem that the opennurbs_ext.h  
header is being treated as a public header and it should not be.   
Looks like step-g is the only thing using it so that can fortunately  
be fixed, but if step-g really (really) needs it, then we really  
should look into wrapping the calls needed through rt_*() functions  
or setting up the extension library before things get too messy.

Cheers!
Sean


------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Reply via email to