From: Diederick C. N. <dc...@gm...> - 2011-10-28 15:19:13
|
Dear All, I've been spurred by the examples provided by John Archdeacon to include the possibility to build 64bit version in the Visual Studio project files. As a first step, I'm trying this out in Visual Studio 2010. Two issued came up. 1: Naming of the output files. Currently, output files are placed in the freeglut root in a folder lib. In that folder there are a folder "Release" for the release builds and a folder "Debug" for the debug builds. dll output files are called freeglut.dll, freeglut.lib and freeglut.exp, whereas freeglut_static.lib is the static library. These names are also automatically set to be import by pragma calls in freeglut_std.h (lines 73 and 87). There are two ways we can add 64 builds to this scheme. One is to add the additional folders "Release64" and "Debug64" into the lib folder to hold the 64bit builds, the other is to suffix 64 to all output files (e.g. freeglut64.dll and freeglut_static64.lib) and mix them in with the 32bit files. The second would also require some trivial changes to freeglut_std.h to change the name of the import libraries requested when building a 64bit project. I've already done this preliminarily and it works well. While i have a preference for the second scheme as the filename then immediately makes clear what version of the libraries you're dealing with, I would like to know what you guys think is best. 2: some linker warnings that crop up in the 64bit version. When the output directories are cleaned and freeglut is built from scratch, a large number of warnings are emitted like this one: "freeglut_callbacks.obj : warning LNK4197: export 'glutIdleFunc' specified multiple times; using first specification" (in fact one for each function in the FreeGLUT API). This does not happen in the 32bit build. Some googling brought up this: http://support.microsoft.com/kb/835326. The issue is that the linker is told twice which symbols to export, once by the __declspec(dllexport) prefixing the API function definitions, and once by the module-definition (freeglut.def) file. While it is harmless, it is something that should be fixed (microsofts advice also notes that while 32bit builds are silent about this double definition, it is also recommended for those to define export symbols only once). It can be fixed by either no longer using the .def file, or by defining the preprocessor symbol FGAPI to empty instead of "__declspec(dllexport)". I've tested removing the .def file and everything builds fine (demos work) for both 64bit and 32bit files. Shall I do this? Or is the .def file also used on non-Windows platforms and would it therefore be better to remove "__declspec(dllexport)" from the function definitions when building the library, as this is a Windows only thing? Thank you for the feedback, even very short replies are much appreciated. Best, Dee |
From: Diederick C. N. <dc...@gm...> - 2011-10-28 15:26:22
|
Dear all, On Fri, Oct 28, 2011 at 23:19, Diederick C. Niehorster <dc...@gm...> wrote: > I've tested removing the .def file and everything builds fine (demos > work) for both 64bit and 32bit files. > Shall I do this? Or is the .def file also used on non-Windows > platforms and would it therefore be better to remove > "__declspec(dllexport)" from the function definitions when building > the library, as this is a Windows only thing? Some grepping reveals that the freeglut.def file is currently only referenced in the VS2008 and VS2010 project files. so lets just get rid of this file, while declarations in the freeglut headers cannot be out of sync with the API by definition, the .def might be forgotten and become out of date. Best, Dee |
From: Diederick C. N. <dc...@gm...> - 2011-10-29 03:29:29
|
Dear all, On Fri, Oct 28, 2011 at 23:26, Diederick C. Niehorster <dc...@gm...> wrote: > Dear all, > > On Fri, Oct 28, 2011 at 23:19, Diederick C. Niehorster > <dc...@gm...> wrote: >> I've tested removing the .def file and everything builds fine (demos >> work) for both 64bit and 32bit files. >> Shall I do this? Or is the .def file also used on non-Windows >> platforms and would it therefore be better to remove >> "__declspec(dllexport)" from the function definitions when building >> the library, as this is a Windows only thing? > > Some grepping reveals that the freeglut.def file is currently only > referenced in the VS2008 and VS2010 project files. so lets just get > rid of this file, while declarations in the freeglut headers cannot be > out of sync with the API by definition, the .def might be forgotten > and become out of date. Ok, complete testing of this issue revealed that to remain binary compatibility and avoid name mangling in the exported sysmbols of dll of the 32bit builds, the def file is needed. for 64bit, names aren't mangled and the def file isn't needed. So the solution is simply to not use the .def file for 64bit builds. Best, Dee |
From: Eero P. <epa...@gm...> - 2011-10-28 18:20:33
|
On Fri, Oct 28, 2011 at 6:19 PM, Diederick C. Niehorster <dc...@gm...> wrote: > Dear All, > > I've been spurred by the examples provided by John Archdeacon to > include the possibility to build 64bit version in the Visual Studio > project files. As a first step, I'm trying this out in Visual Studio > 2010. > I asked about the library naming in August (around 10th). Martin Payne replied: ---------------- I think the convention in MSVC is to keep the lib file names the same on both x86 and x64, but to place the x64 libs into an “x64” subdirectory of your “lib” directory (or “ia64” subdirectory in the case of Itanium). For the x64 build you just need to add the x64 lib path under “additional library directories” in the linker config. I’m not aware of any great advantages of one method over the other, but it might be a good idea to agree on a convention before we make any changes to the freeglut headers. ------------------ So currently my naming convention is something like lib/Debug/freeglut.lib lib/Debug/freeglut_static.lib lib/Release/freeglut.lib lib/x64/Debug/freeglut.lib lib/x64/Release/freeglut.lib etc And in compilation I set the library path to correct directory. Eero Eero |
From: David B. <cyp...@gm...> - 2011-10-28 18:28:34
|
On Fri, Oct 28, 2011 at 1:20 PM, Eero Pajarre <epa...@gm...> wrote: > On Fri, Oct 28, 2011 at 6:19 PM, Diederick C. Niehorster > <dc...@gm...> wrote: > > Dear All, > > > > I've been spurred by the examples provided by John Archdeacon to > > include the possibility to build 64bit version in the Visual Studio > > project files. As a first step, I'm trying this out in Visual Studio > > 2010. > > > I asked about the library naming in August (around 10th). > > Martin Payne replied: > ---------------- > I think the convention in MSVC is to keep the lib file names the same > on both x86 and x64, but to place the x64 libs into an “x64” > subdirectory of your “lib” directory (or “ia64” subdirectory in the > case of Itanium). For the x64 build you just need to add the x64 lib > path under “additional library directories” in the linker config. > > I’m not aware of any great advantages of one method over the other, > but it might be a good idea to agree on a convention before we make > any changes to the freeglut headers. > ------------------ > > So currently my naming convention is something like > lib/Debug/freeglut.lib > lib/Debug/freeglut_static.lib > lib/Release/freeglut.lib > lib/x64/Debug/freeglut.lib > lib/x64/Release/freeglut.lib > > etc > > And in compilation I set the library path to correct directory. > > Eero > I'm fond of that kind of layout, as well. As you said, switching between 32- and 64-bit versions then becomes a simple matter of adding the correct architecture directory to the library search path, rather than appending prefixes to file names. Although I think the 32-bit binaries should go in an x86 directory for the sake of consistency. David |
From: Eero P. <epa...@gm...> - 2011-10-28 18:38:24
|
On Fri, Oct 28, 2011 at 9:28 PM, David Brown <cyp...@gm...> wrote: > I'm fond of that kind of layout, as well. As you said, switching between 32- > and 64-bit versions then becomes a simple matter of adding the correct > architecture directory to the library search path, rather than appending > prefixes to file names. Although I think the 32-bit binaries should go in an > x86 directory for the sake of consistency. But this is Windows ! ;-) It is not like Microsoft dropped win32 or System32 names when going to 64bit. backwards compatibility first. Just kidding, but I think that it might be best to keep to 32bit paths as they are so that we don't break existing setups, just adding the x64 or IA64 (or what it was for Itanium) for new versions should work. Eero |
From: John A. <joh...@gm...> - 2011-10-28 19:17:26
|
A cut / paste below from emails regarding the proposed subdirectory structure that I have been discussing with Dee (dc...@gm...) for the next release. The idea we have been discussing (as I suggested) would to be able to simultaneously build and support all variants on the Windows platform (32-bit DLL and Static Library versions of Release and Debug, 64-bit DLL and static library versions of Release and Debug, and so on). For example, binaries could be stored in the following subdirectories: DebugDLLWin32 DebugDLLx64 DebugStaticWin32 DebugStaticx64 ReleaseDLLWin32 ReleaseDLLx64 ReleaseStaticWin32 ReleaseStaticx64 ... Note: I did not know what the “Template” project rules were so I didn’t build those as I wasn’t clear on what the “Template” was for… easy to fix them up if you desire to keep them in the batch rules. Users decide which binary set to use and can easily incorporate into their project files using the same MACROs (environment variables) supported by Visual Studio itself. For example, when building, the General configuration Output Directory suggested structures looks like this for the DLL builds: .\$(Configuration)DLL$(Platform)\ Note: the VS2010 MACRO variable $(Configuration)=Debug|Release, and $(Platform)=Win32|x64 Temporary (intermediate) files could be stored in: .\$(Configuration)DLL$(Platform)\temp\ For some of my own project work (especially when migrating from Visual Studio 2008 to 2010), I have also been lately using the $(PlatformToolset) MACRO variable (new to VS 2010); this variable is always the value v100. So, if we want to support multiple Visual Studio developer environments the proposed Output directory might better be: .\$(PlatformToolset)\$(Configuration)DLL$(Platform)\ For VS2010, $(PlatformToolset) is always v100 . \v090\$(Configuration)DLL$(Platform)\ For VS2008 builds, the $(PlatformToolset) MACRO variable doesn't exist, so the CMAKE (or project files) would have to explicitly specify it So if this method were preferred, we might propose binary output directories like this: v100\ DebugDLLWin32 DebugDLLx64 DebugStaticWin32 ... v090\ DebugDLLWin32 DebugDLLx64 DebugStaticWin32 ... Of course you could prefix the initial subdirectory name if you wished as well: Windows\v100\... Whatever makes sense! -----Original Message----- From: Eero Pajarre [mailto:epa...@gm...] Sent: Friday, October 28, 2011 11:20 AM To: FreeGLUT developers list Subject: Re: [Freeglut-developer] 64bit versions with Visual Studio On Fri, Oct 28, 2011 at 6:19 PM, Diederick C. Niehorster <dc...@gm...> wrote: > Dear All, > > I've been spurred by the examples provided by John Archdeacon to > include the possibility to build 64bit version in the Visual Studio > project files. As a first step, I'm trying this out in Visual Studio > 2010. > I asked about the library naming in August (around 10th). Martin Payne replied: ---------------- I think the convention in MSVC is to keep the lib file names the same on both x86 and x64, but to place the x64 libs into an “x64” subdirectory of your “lib” directory (or “ia64” subdirectory in the case of Itanium). For the x64 build you just need to add the x64 lib path under “additional library directories” in the linker config. I’m not aware of any great advantages of one method over the other, but it might be a good idea to agree on a convention before we make any changes to the freeglut headers. ------------------ So currently my naming convention is something like lib/Debug/freeglut.lib lib/Debug/freeglut_static.lib lib/Release/freeglut.lib lib/x64/Debug/freeglut.lib lib/x64/Release/freeglut.lib etc And in compilation I set the library path to correct directory. Eero Eero ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Diederick C. N. <dc...@gm...> - 2011-10-29 00:08:30
|
Thank you all for discussion, I'll follow your lead (got plenty of votes in favor for that now, counting MArtin Payne's as well--thanks for that reminder!). Actually, Eero, the layout with VS2008/VS2010 output in \lib was only introduced after freeglut 2.6.0 was released, so we're still free to change things around without having to worry about messing up upgrading users. So lets be consistent (I love consistency). And while editing the strcuture, I'd also want the release builds to look more like the default, just to be sure that inexperienced users are less likely to get in trouble. So a proposed layout would then be: - \lib\x86: release builds - \lib\x86\debug: debug builds - \lib\x64: release builds - \lib\x64\debug: debug builds I don't think we have to split things out over various platforms, just to keep complexity down a bit, but thanks for the suggestion John A.! Also, there's no need to separate the dll and static builds as their filenames don't overlap. Now users could switch to using the static library in their projects by simply defining FREEGLUT_STATIC without having to change any other project settings. Also, I want to make demos actually reachable (right now they're output many levels down in the directory structure) I was thinking to output those into a \demos folder. so: demos\x86\debug_dll demos\x86\debug_static demos\x86\release_dll etc. Is that a good plan? Thank you for all the suggestions! Best, Dee On Sat, Oct 29, 2011 at 03:17, John Archdeacon <joh...@gm...> wrote: > A cut / paste below from emails regarding the proposed subdirectory structure that I have been discussing with Dee (dc...@gm...) for the next release. The idea we have been discussing (as I suggested) would to be able to simultaneously build and support all variants on the Windows platform (32-bit DLL and Static Library versions of Release and Debug, 64-bit DLL and static library versions of Release and Debug, and so on). For example, binaries could be stored in the following subdirectories: > > DebugDLLWin32 > DebugDLLx64 > DebugStaticWin32 > DebugStaticx64 > ReleaseDLLWin32 > ReleaseDLLx64 > ReleaseStaticWin32 > ReleaseStaticx64 > ... > > Note: I did not know what the “Template” project rules were so I didn’t build those as I wasn’t clear on what the “Template” was for… easy to fix them up if you desire to keep them in the batch rules. Users decide which binary set to use and can easily incorporate into their project files using the same MACROs (environment variables) supported by Visual Studio itself. > > For example, when building, the General configuration Output Directory suggested structures looks like this for the DLL builds: > > .\$(Configuration)DLL$(Platform)\ Note: the VS2010 MACRO variable $(Configuration)=Debug|Release, and $(Platform)=Win32|x64 > > Temporary (intermediate) files could be stored in: > > .\$(Configuration)DLL$(Platform)\temp\ > > For some of my own project work (especially when migrating from Visual Studio 2008 to 2010), I have also been lately using the $(PlatformToolset) MACRO variable (new to VS 2010); this variable is always the value v100. So, if we want to support multiple Visual Studio developer environments the proposed Output directory might better be: > > .\$(PlatformToolset)\$(Configuration)DLL$(Platform)\ For VS2010, $(PlatformToolset) is always v100 > . \v090\$(Configuration)DLL$(Platform)\ For VS2008 builds, the $(PlatformToolset) MACRO variable doesn't exist, so the CMAKE (or project files) would have to explicitly specify it > > So if this method were preferred, we might propose binary output directories like this: > > v100\ > DebugDLLWin32 > DebugDLLx64 > DebugStaticWin32 > ... > v090\ > DebugDLLWin32 > DebugDLLx64 > DebugStaticWin32 > ... > > Of course you could prefix the initial subdirectory name if you wished as well: > Windows\v100\... > > Whatever makes sense! > > -----Original Message----- > From: Eero Pajarre [mailto:epa...@gm...] > Sent: Friday, October 28, 2011 11:20 AM > To: FreeGLUT developers list > Subject: Re: [Freeglut-developer] 64bit versions with Visual Studio > > On Fri, Oct 28, 2011 at 6:19 PM, Diederick C. Niehorster <dc...@gm...> wrote: >> Dear All, >> >> I've been spurred by the examples provided by John Archdeacon to >> include the possibility to build 64bit version in the Visual Studio >> project files. As a first step, I'm trying this out in Visual Studio >> 2010. >> > I asked about the library naming in August (around 10th). > > Martin Payne replied: > ---------------- > I think the convention in MSVC is to keep the lib file names the same on both x86 and x64, but to place the x64 libs into an “x64” > subdirectory of your “lib” directory (or “ia64” subdirectory in the case of Itanium). For the x64 build you just need to add the x64 lib path under “additional library directories” in the linker config. > > I’m not aware of any great advantages of one method over the other, but it might be a good idea to agree on a convention before we make any changes to the freeglut headers. > ------------------ > > So currently my naming convention is something like lib/Debug/freeglut.lib lib/Debug/freeglut_static.lib lib/Release/freeglut.lib lib/x64/Debug/freeglut.lib lib/x64/Release/freeglut.lib > > etc > > And in compilation I set the library path to correct directory. > > Eero > > > Eero > > ------------------------------------------------------------------------------ > The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > > ------------------------------------------------------------------------------ > The demand for IT networking professionals continues to grow, and the > demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@Cisco Self-Assessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |
From: Diederick C. N. <dc...@gm...> - 2011-10-29 00:17:47
|
On Sat, Oct 29, 2011 at 08:08, Diederick C. Niehorster <dc...@gm...> wrote: > Also, I want to make demos actually reachable (right now they're > output many levels down in the directory structure) > I was thinking to output those into a \demos folder. > so: > demos\x86\debug_dll > demos\x86\debug_static > demos\x86\release_dll Just remembered we already have a \progs\demos folder. Better build in there instead of in just \demos. Still do you guys think this is a good plan? Best, Dee |
From: John T. <nu...@me...> - 2011-10-29 04:46:11
|
On Fri, Oct 28, 2011 at 11:19:12PM +0800, Diederick C. Niehorster wrote: > It can be fixed by either no longer using the .def file, or by > defining the preprocessor symbol FGAPI to empty instead of > "__declspec(dllexport)". Shall I do this? Or is the .def file also > used on non-Windows platforms and would it therefore be better to > remove "__declspec(dllexport)" from the function definitions when > building the library, as this is a Windows only thing? Both the def file and the __declspec are windows-only things, necessiated by the braindead decision in windows to have symbols private by default, unless declared otherwise. If we have a choice between these two mechanisms and they are not both required, then my opinion is to keep the def file for windows, and remove all the __declspecs that are polluting the code with yet more conditionally compiled code and ugly preprocessor tokens in front of every function. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: Diederick C. N. <dc...@gm...> - 2011-10-29 05:20:23
|
Hi John, On Sat, Oct 29, 2011 at 12:46, John Tsiombikas <nu...@me...> wrote: > On Fri, Oct 28, 2011 at 11:19:12PM +0800, Diederick C. Niehorster wrote: >> It can be fixed by either no longer using the .def file, or by >> defining the preprocessor symbol FGAPI to empty instead of >> "__declspec(dllexport)". Shall I do this? Or is the .def file also >> used on non-Windows platforms and would it therefore be better to >> remove "__declspec(dllexport)" from the function definitions when >> building the library, as this is a Windows only thing? > > Both the def file and the __declspec are windows-only things, > necessiated by the braindead decision in windows to have symbols private > by default, unless declared otherwise. > > If we have a choice between these two mechanisms and they are not both > required, then my opinion is to keep the def file for windows, and > remove all the __declspecs that are polluting the code with yet more > conditionally compiled code and ugly preprocessor tokens in front of > every function. Thanks for the feedback. There is another issue here however. When compiling your program aginst the freeglut header on windows a dllimport dllspec is needed too, so we can't get rid of the extra ugliness in the code in any case :(. It turns out that, to add to the amount of braindead decisions, the def file is needed in 32bit builds as otherwise the functionnames are mangled, by in 64bit builds no mangling happens (apparently) and the def file therefore leads to double export definitions... So its an issue to be resolved in the 64bit project settings only, I'm afriad its not opportunity for clean up, sorry. Best, Dee |
From: Martin P. <li...@ma...> - 2011-10-29 09:26:48
|
Hi Dee, On 29/10/2011 06:20, Diederick C. Niehorster wrote: > It turns out that, to add to the amount of braindead decisions, the > def file is needed in 32bit builds as otherwise the functionnames are > mangled, by in 64bit builds no mangling happens (apparently) and the > def file therefore leads to double export definitions... So its an > issue to be resolved in the 64bit project settings only, I'm afriad > its not opportunity for clean up, sorry. I did stumble across this when I built my 64 bit build. I wouldn't say it's braindead, but just a requirement to maintain binary compatibility with GLUT for Win32 (which uses stdcall and no function decorations). I used the module definition in the 32 bit build, and left it out of the 64 bit build. It doesn't really matter for Win64 since there is only one Win64 calling convention, and there is nothing to maintain backward compatibility with on this platform. I've not had any technical issues with my 64 bit build, nor have I received any reports of issues. The main problems are due to lack of understanding of 64 bit development--mostly people who thought that adding a 64 bit import library to a 32 bit build will make a 64 bit application, or they have had issues compiling a freeglut application on their Windows 7 x64 machine and assumed it's because they need the 64 bit version, or because running "regsvr32" on the 32 bit DLL didn't work so they thought they needed the 64 bit DLL. This is the main reason (other than pending decisions on things like naming) that I haven't made any 64 bit builds publicly available. Regards, Martin |
From: Diederick C. N. <dc...@gm...> - 2011-10-29 16:17:22
|
Hi Martin, On Sat, Oct 29, 2011 at 17:02, Martin Payne <li...@ma...> wrote: > Hi Dee, > > On 29/10/2011 06:20, Diederick C. Niehorster wrote: >> It turns out that, to add to the amount of braindead decisions, the >> def file is needed in 32bit builds as otherwise the functionnames are >> mangled, by in 64bit builds no mangling happens (apparently) and the >> def file therefore leads to double export definitions... So its an >> issue to be resolved in the 64bit project settings only, I'm afriad >> its not opportunity for clean up, sorry. > > I did stumble across this when I built my 64 bit build. I wouldn't say > it's braindead, but just a requirement to maintain binary compatibility > with GLUT for Win32 (which uses stdcall and no function decorations). I > used the module definition in the 32 bit build, and left it out of the > 64 bit build. It doesn't really matter for Win64 since there is only one > Win64 calling convention, and there is nothing to maintain backward > compatibility with on this platform. I meant that it seems braindead that something that was required on win32 builds generates warnings on 64 bit builds. But given your explanation I guess it isn't, thanks! > I've not had any technical issues with my 64 bit build, nor have I > received any reports of issues. The main problems are due to lack of > understanding of 64 bit development--mostly people who thought that > adding a 64 bit import library to a 32 bit build will make a 64 bit > application, or they have had issues compiling a freeglut application on > their Windows 7 x64 machine and assumed it's because they need the 64 > bit version, or because running "regsvr32" on the 32 bit DLL didn't work > so they thought they needed the 64 bit DLL. This is the main reason > (other than pending decisions on things like naming) that I haven't made > any 64 bit builds publicly available. Thats good to hear. I've heard multiple times now that 64bit builds work just fine so including that possiblity in the upcoming release should not be a problem. Its good to know though that it might increase the amount of support requests. But as they come in at the rate of once a month now, we should be able to handle it ;) Thanks for the feedback and the earlier proposal of a naming scheme! Best, Dee |
From: John F. F. <joh...@cy...> - 2011-11-06 13:34:29
|
Folks, In my usual position behind the power curve, I'm only now getting into this discussion. There are a couple of things: (1) On October 28, at 1:38 PM (Central US time), Eero mentioned "backwards compatibility first" and then said he was just kidding. If I may be thoroughly serious, backwards compatibility is extremely important here. We don't want to go yanking our user base around. (2) Are there any code changes that I need to put in? I've not followed the more recent discussions (but hope to get there shortly) so there may be some that I haven't found yet. - John On 10/29/2011 11:17 AM, Diederick C. Niehorster wrote: |
From: Diederick C. N. <dc...@gm...> - 2011-11-06 15:32:32
|
Hi John, On Sun, Nov 6, 2011 at 21:34, John F. Fay <joh...@cy...> wrote: > Folks, > > In my usual position behind the power curve, I'm only now getting > into this discussion. There are a couple of things: > > (1) On October 28, at 1:38 PM (Central US time), Eero > mentioned "backwards compatibility first" and then said he was just > kidding. If I may be thoroughly serious, backwards compatibility is > extremely important here. We don't want to go yanking our user base around. The compatibility issue discussed was whether it is okay to slightly change the paths inside the \lib folder where the various freeglut dlls and static builds are output, to make room for 64bit versions. Eero mentioned that this changing of paths means people would have to change the paths of their linker, this thus breaks backwards compatibility. My opinion is that in this case we do not have to worry about it, as the whole lib folder for output only came into existence after the 2.6.0 release and has thus never shown up in any release. I think it would be a good thing to finalize the strucutre for the future before 2.8.0 goes out, indeed to avoid having to break backwards compatibility later. > (2) Are there any code changes that I need to put in? I've > not followed the more recent discussions (but hope to get there shortly) I have finished new versions of the VS2008 and VS2010 project files, which now also include support for 64bit builds and include the above-mentioned changes to the output paths. I've emailed a zip with the updated project files and a new version of readme.win32 to document the paths where the output can be found. As its too large for the limits of the mailing list, it probably hasn't shown up here yet, but i sent it to your cybertron adres directly as well. I think it is safe to include the 64bit builds as I have heard from multiple people who have been using 64bit builds extensively and haven't met any problems. Of course we'll have to test the release candidate extensively... Thanks for the push to get everything out John! Best, Dee |
From: John F. F. <joh...@cy...> - 2011-11-06 19:50:20
|
OK, I can see a Release Candidate 2 in our near future ... On 11/6/2011 9:32 AM, Diederick C. Niehorster wrote: > Hi John, > > On Sun, Nov 6, 2011 at 21:34, John F. Fay<joh...@cy...> wrote: > >> Folks, >> >> In my usual position behind the power curve, I'm only now getting >> into this discussion. There are a couple of things: >> >> (1) On October 28, at 1:38 PM (Central US time), Eero >> mentioned "backwards compatibility first" and then said he was just >> kidding. If I may be thoroughly serious, backwards compatibility is >> extremely important here. We don't want to go yanking our user base around. >> > The compatibility issue discussed was whether it is okay to slightly > change the paths inside the \lib folder where the various freeglut > dlls and static builds are output, to make room for 64bit versions. > Eero mentioned that this changing of paths means people would have to > change the paths of their linker, this thus breaks backwards > compatibility. My opinion is that in this case we do not have to worry > about it, as the whole lib folder for output only came into existence > after the 2.6.0 release and has thus never shown up in any release. I > think it would be a good thing to finalize the strucutre for the > future before 2.8.0 goes out, indeed to avoid having to break > backwards compatibility later. > > >> (2) Are there any code changes that I need to put in? I've >> not followed the more recent discussions (but hope to get there shortly) >> > I have finished new versions of the VS2008 and VS2010 project files, > which now also include support for 64bit builds and include the > above-mentioned changes to the output paths. I've emailed a zip with > the updated project files and a new version of readme.win32 to > document the paths where the output can be found. As its too large for > the limits of the mailing list, it probably hasn't shown up here yet, > but i sent it to your cybertron adres directly as well. > > I think it is safe to include the 64bit builds as I have heard from > multiple people who have been using 64bit builds extensively and > haven't met any problems. Of course we'll have to test the release > candidate extensively... > > Thanks for the push to get everything out John! > > Best, > Dee > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |
From: John F. F. <joh...@cy...> - 2011-11-06 20:02:26
|
Diederick, Concerning the first part, backward compatibility and the "\lib" folder, I'm not finding a "\lib" folder anywhere. This appears to be specific to Visual Studio 2008 and 2010; is that right? Please pardon my ignorance here. - John On 11/6/2011 9:32 AM, Diederick C. Niehorster wrote: > Hi John, > > On Sun, Nov 6, 2011 at 21:34, John F. Fay<joh...@cy...> wrote: > >> Folks, >> >> In my usual position behind the power curve, I'm only now getting >> into this discussion. There are a couple of things: >> >> (1) On October 28, at 1:38 PM (Central US time), Eero >> mentioned "backwards compatibility first" and then said he was just >> kidding. If I may be thoroughly serious, backwards compatibility is >> extremely important here. We don't want to go yanking our user base around. >> > The compatibility issue discussed was whether it is okay to slightly > change the paths inside the \lib folder where the various freeglut > dlls and static builds are output, to make room for 64bit versions. > Eero mentioned that this changing of paths means people would have to > change the paths of their linker, this thus breaks backwards > compatibility. My opinion is that in this case we do not have to worry > about it, as the whole lib folder for output only came into existence > after the 2.6.0 release and has thus never shown up in any release. I > think it would be a good thing to finalize the strucutre for the > future before 2.8.0 goes out, indeed to avoid having to break > backwards compatibility later. > > >> (2) Are there any code changes that I need to put in? I've >> not followed the more recent discussions (but hope to get there shortly) >> > I have finished new versions of the VS2008 and VS2010 project files, > which now also include support for 64bit builds and include the > above-mentioned changes to the output paths. I've emailed a zip with > the updated project files and a new version of readme.win32 to > document the paths where the output can be found. As its too large for > the limits of the mailing list, it probably hasn't shown up here yet, > but i sent it to your cybertron adres directly as well. > > I think it is safe to include the 64bit builds as I have heard from > multiple people who have been using 64bit builds extensively and > haven't met any problems. Of course we'll have to test the release > candidate extensively... > > Thanks for the push to get everything out John! > > Best, > Dee > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |
From: Diederick C. N. <dc...@gm...> - 2011-11-07 00:33:02
|
Hi John, Indeed it is. It is created when compiing with vs2008 or vs2010, so its not somehting that has to go into SVN, its in the project file settings. Best, Dee On Mon, Nov 7, 2011 at 04:02, John F. Fay <joh...@cy...> wrote: > Diederick, > > Concerning the first part, backward compatibility and the "\lib" > folder, I'm not finding a "\lib" folder anywhere. This appears to be > specific to Visual Studio 2008 and 2010; is that right? > > Please pardon my ignorance here. > > - John > > > On 11/6/2011 9:32 AM, Diederick C. Niehorster wrote: >> Hi John, >> >> On Sun, Nov 6, 2011 at 21:34, John F. Fay<joh...@cy...> wrote: >> >>> Folks, >>> >>> In my usual position behind the power curve, I'm only now getting >>> into this discussion. There are a couple of things: >>> >>> (1) On October 28, at 1:38 PM (Central US time), Eero >>> mentioned "backwards compatibility first" and then said he was just >>> kidding. If I may be thoroughly serious, backwards compatibility is >>> extremely important here. We don't want to go yanking our user base around. >>> >> The compatibility issue discussed was whether it is okay to slightly >> change the paths inside the \lib folder where the various freeglut >> dlls and static builds are output, to make room for 64bit versions. >> Eero mentioned that this changing of paths means people would have to >> change the paths of their linker, this thus breaks backwards >> compatibility. My opinion is that in this case we do not have to worry >> about it, as the whole lib folder for output only came into existence >> after the 2.6.0 release and has thus never shown up in any release. I >> think it would be a good thing to finalize the strucutre for the >> future before 2.8.0 goes out, indeed to avoid having to break >> backwards compatibility later. >> >> >>> (2) Are there any code changes that I need to put in? I've >>> not followed the more recent discussions (but hope to get there shortly) >>> >> I have finished new versions of the VS2008 and VS2010 project files, >> which now also include support for 64bit builds and include the >> above-mentioned changes to the output paths. I've emailed a zip with >> the updated project files and a new version of readme.win32 to >> document the paths where the output can be found. As its too large for >> the limits of the mailing list, it probably hasn't shown up here yet, >> but i sent it to your cybertron adres directly as well. >> >> I think it is safe to include the 64bit builds as I have heard from >> multiple people who have been using 64bit builds extensively and >> haven't met any problems. Of course we'll have to test the release >> candidate extensively... >> >> Thanks for the push to get everything out John! >> >> Best, >> Dee >> >> ------------------------------------------------------------------------------ >> RSA(R) Conference 2012 >> Save $700 by Nov 18 >> Register now >> http://p.sf.net/sfu/rsa-sfdev2dev1 >> _______________________________________________ >> Freeglut-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |
From: Eero P. <epa...@gm...> - 2011-11-07 08:05:54
|
I am sending this message, just to say that I don't oppose Diederick's reasoning, and it is good time to set the directory names now. Eero |
From: Diederick C. N. <dc...@gm...> - 2011-11-07 09:03:28
|
thanks for the feedback Eero! Are others okay with the current setup of release builds in /lib/x86 and /lib/x64, and Debug builds in /lib/x86/Debug and /lib/x64/Debug? Better ideas are always welcome! Best, Dee On 07/11/2011, Eero Pajarre <epa...@gm...> wrote: > I am sending this message, just to say that I don't oppose Diederick's > reasoning, and it is good time to set the directory names now. > > > Eero > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |
From: John F. F. <joh...@cy...> - 2011-11-07 12:20:13
|
Eero, I think I've put the proper directory names in. Please check that I've done it correctly. - John On 11/7/2011 2:05 AM, Eero Pajarre wrote: > I am sending this message, just to say that I don't oppose Diederick's > reasoning, and it is good time to set the directory names now. > > > Eero > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > |