Re: [xml-cppdom-devel] Versioned directories on Windows

[Allen B. <al...@vr...>]

Aron Bierbaum wrote:

>I agree with you 100% on this. I think that introducing versioned header 
>directories on Windows is only going to further complicate things. I 
>can't say that I know how a lot of packages handle this on Windows. But 
>I do know that Qt defaults to being installed in C:\Qt\4.1.4\. This 
>sounds very similar to how we could handle it. C:\Program 
>Files\gmtl\0.5.0  and C:\Program Files\cppdom\0.6.5
>
>-Aron
>  
>
This sounds fine with me. Windows is an anomaly so lets just make it 
easy on ourselves and use something that will work for what we need.

-Allen

>
>Patrick Hartling wrote:
>  
>
>>Sorry for the cross posting, but this involves both CppDOM and GMTL. I
>>recently made the statements below on the vrjuggler-devel mailing list and
>>have received no comments, criticisms, or feedback. This is an important
>>issue that needs to be resolved, so here is what I said:
>>
>>===========================================================================
>>
>>Versioned Header and Data Directories on Windows
>>------------------------------------------------
>>
>>Getting back to the parallel installation topic, Windows has been updated to
>>created versioned DLLs and to generate .fpc files for building against VR
>>Juggler from the command line (yes, that is finally supported again).
>>However, the header and data directories are not currently being versioned
>>the way that they are on non-Windows platforms, and a decision needs to be
>>made regarding whether it is necessary to do that.
>>
>>My vote on this topic is not to version the header or data directories on
>>Windows. Deployment on Windows is fundamentally different than on other
>>operating systems because there is no equivalent of /usr/include (or
>>/usr/local/include) or /usr/share (or /usr/local/share). Rather, software
>>on Windows usually goes into C:\Program Files\<directory> where <directory>
>>can be named with a version. This makes parallel installations easier since
>>the files are separated at a higher level in the directory structure. It
>>also makes it easier to handle Visual C++ project files since they don't
>>have to be updated to track the name of the include directories (which could
>>require a lot of work since there are would be one /I option needed for each
>>Juggler module). Structuring things this way is what the Boost Consulting's
>>slick installer for Boost on Windows does, and I would apply this same
>>argument to CppDOM and GMTL.
>>
>>===========================================================================
>>
>>Thoughts?
>>
>> -Patrick
>>
>>
>>  
>>------------------------------------------------------------------------
>>
>>-------------------------------------------------------------------------
>>Take Surveys. Earn Cash. Influence the Future of IT
>>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>>opinions on IT & business topics through brief surveys -- and earn cash
>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Xml-cppdom-devel mailing list
>>Xml...@li...
>>https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
>>  
>>    
>>
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>Xml-cppdom-devel mailing list
>Xml...@li...
>https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
>
>  
>