Note: I changed the name of the clonk executable to clonk-bin to reserve the name for the actual command to run it. (In the CMakeFile I let create an shellscript which changes the directory to the right dir and then executes "clonk-bin")
Also this isn't really a wise thing to do with an (let's say)actively developed game....
- The clonk binary doesn't change its name, write "runclonk" to run it from the correct working directory
- CPack support! CPack is an tool connected with CMake to generate RPMs, DEBs, Source Packages, Windows Installer and Mac Bundles. (It generally works now but I've not tested it fully yet)
Can you also describe how to use CPack to generate these RPMs, DEBs, etc.? At least on the CM here, nobody has any experience with CPack. :-/
"Installation Support V2 (Including CPack Support)" is the correct one, you can simply strip the other one.
to generate those packages simply write "cpack -G RPM" to generate an RPM, you can generate an DEB by replacing the RPM through DEB. Other possible values are NSIS (Windows Installer, however, you might want/should to add some additional info in the CMakeLists.txt, see link) plus STGZ, TBZ2, TGZ, TZ and ZIP (all simple archives with different compression.)
But how is it possible to create a nullsoft installer - where do I get the windows binaries from under linux then?
P.S.: If you didn't know: CPack is part of CMake, so if you have CMake you have also CPack
In a followup patch, I changed the following:
* Pack game data after installation
* Remove the icons and install from src/res/oc.ico instead, so that if we update the icon ony day we install the new icon automatically
* Remove the runclonk script, instead add support for loading from a different path into the engine (as an extra patch)
I am going to push this in a few days if nobody points out obvious or potential problems with the engine changes.
- Just remove all unused code, don't comment it out.
- I Clonk, we use simple global variables for singletons. Reloc.Paths is a lot simpler to read and understand than C4RelocImpl::Instance().Paths. It also saves a few lines of code.
- C4GroupSet does something similar. Have you checked whether C4Reloc could share code with it?
Looks good otherwise. Thanks for working on this.
> I Clonk, we use simple global variables for singletons. Reloc.Paths is a lot simpler to read and understand than C4RelocImpl::Instance().Paths. It also saves a few lines of code.
The reason I did it this way is to make sure that the class gets instantiated after C4Config has been loaded. If it was a global variable I guess some Init() function would need to be called explicitely.
> C4GroupSet does something similar. Have you checked whether C4Reloc could share code with it?
Not so easily at least, because C4GroupSets operates on open C4Groups, and C4Reloc can be used to find any files at a system path. The relation between the two is rather so that there could be a method in C4Reloc which adds all groups of the same name into a C4GroupSet and returns that; for example to load languages from Language.c4g from both UserDataPath and SystemDataPath.
> The reason I did it this way is to make sure that the class gets instantiated after C4Config has been loaded. If it was a global variable I guess some Init() function would need to be called explicitely.
Wow, that's incredibly subtle. Do you know how the compiler arranges for the static variable to be initialized? I thought all static variables were initialized before main(), regardless of whether they were in a function or global. Hm, looking at the patch again... Er, are you sure that it isn't the call to ClearPaths in C4Application::DoInit that's responsible for making it work, with empty paths before that point?
> Wow, that's incredibly subtle. Do you know how the compiler arranges for the static variable to be initialized?
According to this it basically inserts a boolean "initialized" flag.
> Er, are you sure that it isn't the call to ClearPaths in C4Application::DoInit that's responsible for making it work, with empty paths before that point?
Yes, I am certain. It is guaranteed that static (non-POD) variables are initialized when the function is first called (section 6.7.4 in the C++ standard). Well, I am not strictly opposed to changing it to be a simple global variable instead; just thought it was cleaner this way.
Normally, I am not the guy who reviews and finally applies community patches so I don't really know much about the situation and if the situation we have now is satisfactory. Your opinions?
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill