David,
Something else to bear in mind is the magnitude of the effort. A
quick search through the code showed about 190 places where
platform-specific code is found. I don't want 80-90 different code
snippets (or functions) in one file without a lot of rhyme and reason.
If we go with separate files for the different original "freeglut"
files, we can also hold off on the joystick refactoring if we don't want
to tackle it right away.
- John
On 1/8/2012 1:47 PM, David Brown wrote:
> John,
>
> I think that would work. I'm personally fond of keeping
> platform-specific code in a single file in my own projects, but that
> doesn't really have a functional impact, so it's just a matter of
> preference. As the code stands now, platform-specific bits are chosen
> with preprocessor conditionals and are nicely separated. It would just
> be a simple matter of copying each of those sections into their
> respective platform file(s). The only problem area I see is the
> joystick code. It looks like it might be difficult to refactor, but as
> it appears to already support Windows, Linux, and Mac OSX, refactoring
> might not even be required right away.
>
> -- David
>
>
> On Sun, Jan 8, 2012 at 1:20 PM, John F. Fay <johnffay@...
> <mailto:johnffay@...>> wrote:
>
> David,
>
> Many thanks for your reply and also for the "cmake" file in
> the first place. It looks like the consensus on the list is to go
> with "cmake" and it looks quite good to me, so I'll give it a 90
> percent chance that that is the direction we're going.
>
> Concerning the extra files, I am VERY interested in new
> platform support, so anything that would make it easier is good in
> my book. To that end, I'm pretty sure that we will go with
> splitting off the system-specific source code into its own source
> files.
>
> Right now the main question in my mind about the
> system-specific source code is how we should arrange the files.
> I'm a great fan of smaller source code files, so I hesitate to
> make a single large "freeglut_windows.c" file. I'm leaning more
> towards a set of files: "freeglut_cursor_ms_windows.c",
> "freeglut_cursor_posix_x11.c", "freeglut_display_ms_windows.c",
> "freeglut_display_posix_x11.c", and so on.
>
> What do you think?
>
> - John
>
>
> On 1/8/2012 12:30 PM, David Brown wrote:
>> On Sat, Jan 7, 2012 at 11:00 PM, John F. Fay
>> <johnffay@... <mailto:johnffay@...>> wrote:
>>
>> OK, I fixed my error and removed the references to the
>> platform-specific files. Now I get project and workspace
>> files but they're all jumbled up in one directory. Progress,
>> I guess.
>>
>>
>> - John
>>
>>
>> You can remove those lines completely, if you like (I notice
>> they're just commented out now). They were left over from an
>> experiment I did, so the standard FreeGLUT distribution obviously
>> doesn't include them.
>>
>> On Sun, Jan 8, 2012 at 12:01 PM, Paul Martz
>> <pmartz@... <mailto:pmartz@...>> wrote:
>>
>> On 1/8/2012 10:25 AM, Martin Payne wrote:
>> > Running the demos really should be a
>> > case of hitting the "run" button in Visual Studio, but
>> currently the DLL
>> > and executables are placed in different directories,
>>
>> I *think* there's a CMake setting to write the DLLs into the
>> same dir as the
>> EXEs, but not sure what it is. I'll sift through the CMake
>> docs and see if I can
>> dig it up.
>>
>>
>> The CMakeLists.txt file currently places shared and static
>> libraries in "lib" and demos in "bin." This is configured on
>> lines 38 and 39 of revision 971:
>>
>> SET(EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/bin)
>> SET(LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR}/lib)
>>
>> I believe if you remove them, it'll place everything in the build
>> directory. If not, just set them both to ${PROJECT_BINARY_DIR} to
>> achieve the same thing. As for fractals.dat, CMake 2.8 includes a
>> FILE COPY command that should be able to solve that issue
>> (http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command%3afile).
>> In that case, CMAKE_MINIMUM_REQUIRED would need to be changed to
>> VERSION 2.8 to ensure that the command is available.
>>
>>
>> -- David
>>
>>
>> ------------------------------------------------------------------------------
>> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
>> infrastructure or vast IT resources to deliver seamless, secure access to
>> virtual desktops. With this all-in-one solution, easily deploy virtual
>> desktops for less than the cost of PCs and save 60% on VDI infrastructure
>> costs. Try it free!http://p.sf.net/sfu/Citrix-VDIinabox
>>
>>
>> _______________________________________________
>> Freeglut-developer mailing list
>> Freeglut-developer@... <mailto:Freeglut-developer@...>
>> https://lists.sourceforge.net/lists/listinfo/freeglut-developer
>>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
> complex
> infrastructure or vast IT resources to deliver seamless, secure
> access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI
> infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Freeglut-developer mailing list
> Freeglut-developer@...
> <mailto:Freeglut-developer@...>
> https://lists.sourceforge.net/lists/listinfo/freeglut-developer
>
>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
>
>
> _______________________________________________
> Freeglut-developer mailing list
> Freeglut-developer@...
> https://lists.sourceforge.net/lists/listinfo/freeglut-developer
>
|