Menu
▾
▴
xml-cppdom-devel
|
From: Patrick H. <pa...@13...> - 2006-09-27 13:36:33
Attachments:
signature.asc
|
Sorry for the cross posting, but this involves both CppDOM and GMTL. I recently made the statements below on the vrjuggler-devel mailing list an= d have received no comments, criticisms, or feedback. This is an important issue that needs to be resolved, so here is what I said: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= 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 versione= d the way that they are on non-Windows platforms, and a decision needs to b= e 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 <director= y> can be named with a version. This makes parallel installations easier sin= ce 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 co= uld require a lot of work since there are would be one /I option needed for e= ach 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. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Thoughts? -Patrick --=20 Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2oum9 | http://www.infiscape.com/ |
|
From: Aron B. <ar...@ia...> - 2006-09-27 14:41:35
|
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 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 > |
|
From: Allen B. <al...@vr...> - 2006-09-27 15:12:41
|
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 > > > |
|
From: subatomic <ke...@su...> - 2006-09-27 16:40:36
|
totally agree... and, if you need to change names on anything, do it on the filename... i.e. cppdom-1.4.5.dll cppdomD-1.4.5.dll but keep it in the local directory... having these global stores (first the registry, now the dll database in windows) seems prone to errors, or if nothing else, really inconvenient and like you say, different than any other platform. Are there issues with two running apps accessing the same name of dll (but in different folders)?? If so, you may want to do the naming thing I mentioned above... Otherwise, why add the complication.... - kevin On 9/27/06, Allen Bierbaum <al...@vr...> wrote: > > 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 > > > > > > > > > ------------------------------------------------------------------------- > 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 > _______________________________________________ > ggt-devel mailing list > ggt...@li... > https://lists.sourceforge.net/lists/listinfo/ggt-devel > -- Kevin Meinert http://www.subatomicglue.com |
|
From: subatomic <ke...@su...> - 2006-09-27 16:42:19
|
>> Are there issues with two running apps accessing the same name of dll (but in different folders)?? to clarify... I was talking about 2 apps, accessing the same name dll from different locations, each of which is a different version than the other... On 9/27/06, subatomic <ke...@su...> wrote: > > > totally agree... > and, if you need to change names on anything, do it on the filename... > i.e. > cppdom-1.4.5.dll > cppdomD-1.4.5.dll > > but keep it in the local directory... > having these global stores (first the registry, now the dll database in > windows) seems prone to errors, or if nothing else, really inconvenient and > like you say, different than any other platform. > > > Are there issues with two running apps accessing the same name of dll (but > in different folders)?? > If so, you may want to do the naming thing I mentioned above... > Otherwise, why add the complication.... > > - kevin > > On 9/27/06, Allen Bierbaum <al...@vr...> wrote: > > > > 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 > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------- > > 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 > > _______________________________________________ > > ggt-devel mailing list > > ggt...@li... > > https://lists.sourceforge.net/lists/listinfo/ggt-devel > > > > > > -- > Kevin Meinert > http://www.subatomicglue.com -- Kevin Meinert http://www.subatomicglue.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X