View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002074CMakeModulespublic2005-07-23 04:192008-08-21 15:58
ReporterEric Wing 
Assigned ToBill Hoffman 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0002074: Submission for FindSDL_sound.cmake
DescriptionI would like to submit a new module for finding SDL_sound.

This one is a bit more complex than the other SDL family of modules I submitted because SDL_sound can be compiled in many different ways which could introduce different dependencies which are independent of platform. For some platforms/compilers I've encountered, I've been forced to explicitly link against any dependencies of SDL_sound when I use SDL_sound. Since there is no easy way of knowing if/what I need to link to, this module does that detection and finds the libraries you need.

Because of the complexity of this module, it probably needs more scrutiny, but I'm reaching then ends of what I'm capable of testing. I can say it works on my systems, OS X (Tiger), Debian Sarge, and Windows XP (under VS7.1 and Msys) with the ways that I've built it. But this doesn't really cover all the potential variations of how SDL_sound was built or compilers (since I have to parse error output). But it will hopefully work for the common cases without problems at least.

One shortcoming I do not know how to fix is how to get the GUI to update with the final SDL_SOUND_LIBRARIES string. When dependencies are required, I build up a string containing all the required dependencies, but the GUI only reflects the value the first time I set the variable. Using the FORCE modifier seems to change it, but it also seems to prevent the user from setting the value which is not what I want. I want the user to be able to modify the value in case I do miss something. Maybe somebody more knowledgeable can fix this.
TagsNo tags attached.
Attached Files? file icon FindSDL_sound.cmake [^] (13,971 bytes) 1969-12-31 19:00
zip file icon FindSDL_sound_r3.zip [^] (4,925 bytes) 1969-12-31 19:00

 Relationships

  Notes
(0002874)
Bill Hoffman (manager)
2005-08-10 12:03

I have commited this to cvs, please try. I have attempted to fix your problem. All I did was create a libraries_tmp var and build things up in that, it is a non-cached variable, and at the end of the module, I cache the result. SDL_SOUND_LIBRARIES_TMP is used with a final cached SDL_SOUND_LIBRARIES.

Please try it and make sure i did not break it.
Thanks.
(0003006)
Eric Wing (reporter)
2005-09-09 20:50

I tested your changes to the file and they seem to work great. Thank you for making the enhancements. There is one minor thing I am wondering about. In the case where a package is not found and the user must manually add it or a user changes something in the CMake menu, I notice that the SDL_SOUND_LIBRARIES string still faces the original problem where it only visually reflects the initial setting. Is there a way to handle this?
If we can perfect these minor issues, I would like to backport the changes to the FindSDL.cmake module as it suffers from a similar (but simpler version of these problems).

Thanks,
Eric

(0003008)
Bill Hoffman (manager)
2005-09-12 09:48

If it is not found, then the user has to SDL_SOUND_LIBRARIES in the cmake cache via ccmake or CMakeSetup. I don't see the problem?
(0003009)
Eric Wing (reporter)
2005-09-12 14:12

Actually, my expectation of how the module will be used is a little different. Say for example that just one of the support libraries like Vorbis is not found because it is located in a non-standard path. The CMake UI will visibly show that the Vorbis library is not found so I think the natural tendency is to fill that field properly. My additional hope would be that the user would not need to ever directly modify the SDL_SOUND_LIBRARIES field and treat it as read-only (except for bizarre circumstances where I failed to predict the build pieces required to generate the string).

Currently, the SDL_SOUND_LIBRARIES variable does in fact automatically update itself to include the fixed Vorbis field. However in the UI, you would not see this because the string in the UI doesn't get updated to reflect this new state.

As I said, it's kind of a minor problem, but I think it would go a long way to make it clear to the user what's going.

Thanks,
Eric


(0003010)
Bill Hoffman (manager)
2005-09-12 16:01

One thing we could do is make SDL_SOUND_LIBRARIES an internal variable that users can not modify. Users would just have to modify the components of SDL_SOUND_LIBRARIES. You could even add a SDL_SOUND_LIBRARIES_EXTRA variable that people could put anything into.
(0003011)
Eric Wing (reporter)
2005-09-12 16:39

I like that idea. How difficult would it be to make those changes to the existing infrastructure?
(0003030)
Eric Wing (reporter)
2005-09-18 04:10

I made the SDL_SOUND_LIBRARIES variable internal and added a SDL_SOUND_EXTRAS field as discussed. (I'm not sure if there is a convention for the name of the EXTRAS variable, so please correct me if there is.)

I also made some painful fixes to the OS X framework detection system because I overlooked the cases where the framework does not lie in the default search paths. Since CMake does not currently handle frameworks as it does other libraries, this needed to be handled directly in the module itself.
(0003031)
Eric Wing (reporter)
2005-09-18 04:13

I forgot to mention that I also added more search paths to catch other packaging systems and variations I forgot last time around (DarwinPorts, Blastwave).

 Issue History
Date Modified Username Field Change
2008-08-21 15:58 Bill Hoffman Status assigned => closed


Copyright © 2000 - 2018 MantisBT Team