There are two targets you may not be familiar with, `install` and `package`.
* For Linux, `install` now defaults to `/usr/local`, but you can set it back to `/opt` with `cmake -DCMAKE_INSTALL_PREFIX=/opt` if you wish.
* For Windows, `install` may not work, but this is not a target you would want usually.
* For Linux, `package` has not been tested yet. It will likely create an archive file of what is installed.
* For Windows, `package` will create an NSIS package that can be used to install StepMania. One minor change as a result is that the binary and companion dlls will be placed in `bin` instead of `Program` now, but it makes no difference code-wise.
Mac OS X users: for now, use the `dmg` target instead.
This commit does *not* deprecate the original nsi script yet. The Texture Font Generator program has not been addressed yet.
* Replace `string(CONCAT ...)` with an equivalent call for the cmake 2.8.12 users.
* Use `execute_process` instead of the deprecated `exec_program`. This will work regardless of version (assuming the minimum is met at least).
This should address issue #549.
I moved a MESSAGEMAN:Broadcast() call so that it only broadcasts the setting that has been saved. This seems more sensible to me, but it is possible I'm misinterpreting the original design here.
Feel free to merge or not merge this commit. :)
As noted in my previous commit message, I think ThemePrefs.ForceSave() can safely be deprecated. Since many novice themers look to default when learning, I think it's better to use ThemePrefs.Save() as the system was originally designed.
I moved the ThemePrefs.Save() call out of ScreenTitleMenu decoration to ScreenOptionsService in. This seems safer to me; Pay/Freeplay never hit ScreenTitleMenu which could be another reason ThemePrefs would never get saved.
Additionally, moving the call to ScreenOptionsService in also seems to have fixed a bug where switching themes via the Appearance Options service menu would cause the new theme to inherit all of the previous theme's ini settings. I'm still not entirely sure why.
I've done a fair amount of testing with this.
I've tried deleting the ThemePrefs.ini file outright and booting fresh into both default and Simply Love. In both cases, the ThemePrefs.ini file is written when StepMania exits or when the user hit ScreenOptionsService, whichever comes first.
I've tried switching between various themes, including those that did not use ThemePrefs. I haven't seen any sections being created erroneously and themes that do use ThemePrefs don't seem to inherit the previous theme's settings any longer.
Still, it *very* possible that I've missed some edge case(s) and is probably worth a few people testing before merging.
The ThemePrefs table contains several functions and single standalone variable, NeedsSaving. When a themer calls ThemePrefs.Save() the system will check the status of NeedsSaved to determine whether it really needs to save or not. This is by design to prevent unnecessary writing to disk.
As far as I am able to discern, NeedsSaved would never be anything but false due to scoping within the ThemePrefs table. This commit properly scopes that variable as it used within the functions.
It looks like ThemePrefs.ForceSave() was added as a workaround; it didn't check the status of NeedsSaved and just always saved, "no matter what." Though it seems safe to outright remove ForceSave(), I'm leaving it in for compatibility. Consider it deprecated I suppose.
false is a perfectly valid setting for one of SM's ini files. The code here needs to ensure that both the key (string) and the value (string, numeric, boolean) read from file exist. It would previously halt if the value was set to false. This fixes that by explicitly checking for nil.
* Disable warning output during configuration.
* Allow users to turn on warnings for ffmpeg and other internal projects.
* Add a new variable for easier ffmpeg version migration if we ever
* pursue that.
A new target is introduced called `dmg`. This must be run explicitly.
Upon running it, it creates the dmg file.
The target respects if we are in a full release or not.
This will officially deprecate the ruby release script in the Xcode
folder upon a successful merge.
* `set_target_properties` can have multiple properties assigned in one go.
* Have version information be generated from CMake, not later plist preprocessing.
* Configure the plist file regardless of OS. This should be a safe command: following the example from the knut repository.
The old fashioned Info-StepMania.plist file can be considered deprecated
upon a full migration to CMake.
tuxdude143