For me the question is: Why do you want to push a change to default that generates problems/work for anyone using MSVC? As long as the is no big gain for this, I don't see a reason for this change.
> It is already pushed, and I guess less than 10% of windows devs use an out of tree build
if you followed the tutorial in the wiki, you will have an out of tree build - nearly everyone used the tutorial to set up his environment.
> like MSVC wasn't really able to use BUILD_TO_PLANET because the files would have overwritten themselves in planet anyway
I used it for years.
Also, symlink and windows?
Also, isn't it about time that we stop calling it "planet"? Maybe "game" or "data"?
The setup I'm using is a symlink from DWCC/planet to planet/ in the source directory, and I'm starting the engine with ./clonk planet/Tests.ocf/Minimal.ocs or just ./clonk. Also, for occasional tests with MSVC, I simply made the DWCC be the repository directory. You don't need multiple DWCC for release and debug builds with MSVC, and the average casual windows developer won't need them for crosscompiling or other experiments.
Plus, as I said, it also neatly works around TortoiseHg crashing, which it always does as long as the build directory happens to be a directory Mercurial looks at.
/path/to/build/dir/CMakeCache.txt
/path/to/build/dir/planet -> /path/to/repos/planet
/path/to/repos/CMakeLists.txt
And either
/path/to/build/dir/clonk$(EXEEXT)
or
/path/to/build/dir/$(CONFIGURATION)/clonk$(EXEEXT)
But I haven't actually tested that on windows. And it doesn't involve any symlinks in the repository, so TortoiseHG doesn't have any reason at all to complain.
Anyway, your patch breaks crosscompilation and presumably building with Windows XP. While I don't particularly care about the latter, I don't think we should invest too much time into making this work reliably. While out-of-tree builds are nice, in-tree builds work fine for most people and can be made to work without symlinks.
> Did you check why the code in C4Reloc which took CMAKE_INTDIR into account didn't work?
Didn't it work? I didn't check. I just think that no matter whether it worked or not, hard-coding properties of the build system into the binary is the wrong way to do it. Sooner or later we might get terribly confused by the MinGW build behaving slightly differently from the MSVC build.
> and presumably building with Windows XP.
Hm, that's trickier. Maybe we should simulate that by making "data" a text file that points to the correct location or something? Wouldn't be too hard.
> Anyway, your patch breaks crosscompilation
Hardly surprising - it is a pretty radical change. Any pointers on what goes wrong? Does it try to "mklink" under Linux or something?
> I just think that no matter whether it worked or not, hard-coding properties of the build system into the binary is the wrong way to do it. Sooner or later we might get terribly confused by the MinGW build behaving slightly differently from the MSVC build.
That's already the case, and it is very obvious that a change of the relative directory needs to result in a change somewhere. If you aren't confused that the msvc build puts your symlink into a different place you aren't going to be surprised that the binary looks in a different place, too. Remember, the installed binary finds the data files the same way, so we don't need to remember which compiler built the release binaries. If this is the only reason for your change, I'm for simply reverting it.
> Hardly surprising - it is a pretty radical change. Any pointers on what goes wrong? Does it try to "mklink" under Linux or something?
Yes, see the linked log.
I don't have much against creating the symlink from cmake, but that should be a simple optional step. You only need it when you want to start the game without installing it first.
So I guess we could make that a CMAKE variable that you can activate, like BUILD_TO_PLANET? I could just parameterize the whole behaviour - with possibly different defaults per platform - then everybody's happy on some level.
<Guenther> So, anybody else an opinion on http://forum.openclonk.org/topic_show.pl?tid=859
<ck> make cross-compiling work again, please
<Guenther> what's your general opinion on how the engine should get the unpacked data from the repository?
<ck> It should read the files in planet/
<Isilkor> when cross-compiling, we shouldn't create any symlinks at all
<Isilkor> because the generated binary won't run on the host anyway, so why have a symlink there
<Guenther> Isilkor: wine
<Isilkor> what I'm doing at home is I have a symlink in planet to each of the binaries
<Guenther> on windows?
<Isilkor> yes
<ck> I don't think the Makefile should create any symlinks
<Isilkor> I don't think so either
<Guenther> I kinda like a symlink to planet from the build dir to the source dir for the case where the two aren't the same
<Guenther> since you're presumably using an otherwise empty build dir for an out-of-tree build
<Isilkor> I am
<Isilkor> I'm both using an out-of-tree build at home and for the autobuilds
<Guenther> Should the binary know it got created in a Release/ or Debug/ etc. directory and search in ../planet or ./planet, or should we use symlinks to make both cases look the same for the binary?
<Isilkor> that's tricky
<Isilkor> I would be in favor of not special-casing MSVC, but that'll make things weird for newbies who just want to compile their stuff themselves by following our tutorial
<Guenther> There's no special casing specifically MSVC, it's all CMake that configures those paths
<Isilkor> I mean having MSVC builds search for their files in multiple locations, while g++ builds don't
<Isilkor> or a different location, for that matter
<Isilkor> basically I shouldn't have to care about whether I use a MSVC binary or a g++ binary in the end, I just drop it at a specified location and it works
<Isilkor> if that's planet or planet/.. isn't really the issue I believe
<Isilkor> from an end-user perspective, I mean
<Guenther> Well, if you move the binary, you should just use the search path used by installed binaries
<Isilkor> I clone the repos, and drop a prebuilt openclonk.exe into whatever directory, and it should work
<Guenther> Well, on windows that happens to work
<ck> what about building release and debug engines into the same directory but calling them differently?
<Isilkor> ck: that's what BUILD_TO_PLANET did, I believe
<Guenther> we could reuse that logic, but put the binaries into the build dir instead of the repos/planet dir
<Guenther> and not make it an option
<ck> I don't mind whether the binary ends up in planet or elsewhere
<ck> Just to avoid special casing MSVC
<Isilkor> I do mind when it ends up in planet, because planet is outside of my build root
<Isilkor> building to the build root would work just fine for me though
<Guenther> And I also don't want to bring the option back
<Guenther> That would be way worse than making multi-config cmake targets work differently
<Isilkor> we should just build it to ${CMAKE_CURRENT_BINARY_DIR}/openclonk{-debug,-minsizerel,-relwithdebinfo}
<Isilkor> unconditionally
<Isilkor> but have either the release or the release+debuginfo binary just called openclonk
We then argued some more, but didn't arrive at any better solution. (Though continuing to call the release binary clonk(.exe) would be less work than switching to openclonk(.exe)) I think Isilkor volunteered to do the CMake work. :-)
> <Isilkor> because the generated binary won't run on the host anyway, so why have a symlink there
On the other hand - it doesn't hurt either, does it? I feel like making sure that you can actually do something with the binary no matter what paths you configured is good practice.
If people feel symlinks are the wrong way to do it - especially on Windows - we could think about just leaving a file there, like I proposed earlier. Maybe support loading configuration (as in C4Config) partially from a file, then have CMake generate one, overwriting the system data path? I don't know, there's a lot of ways we can do this. I think we are giving up on the out-of-tree-build feature a bit too hastily :)
> <Isilkor> we should just build it to ${CMAKE_CURRENT_BINARY_DIR}/openclonk{-debug,-minsizerel,-relwithdebinfo}
Fair enough, I guess that's the safe solution. Note though that this is positively incompatible with how Mac builds work.
> Note though that this is positively incompatible with how Mac builds work.
The Mac build is sufficiently different from everything else that I didn't want to touch it. Especially since I don't have one, nor do I have any experience with compiling/packaging OS X software.
> I think we are giving up on the out-of-tree-build feature a bit too hastily :)
I've been building Clonk exclusively out-of-tree for years, and will continue to do so. I wouldn't call that "giving up".
> I think Isilkor volunteered to do the CMake work. :-)
"This changeset also revives looking for game data in the same directory as the binary" is wrong. On windows, SystemDataPath is the exepath. So all the patch did in that regard is to move the UserDataPath behind the SystemDataPath on windows (and the Linux releases using the same layout), while platforms with a different SystemDataPath will have the UserDataPath first. I think that's unfortunate.
Also, is MSVC really the only multi-configuration CMake target? I think the test should be for that, not for one specific CMake target.
> Also, is MSVC really the only multi-configuration CMake target? I think the test should be for that, not for one specific CMake target.
CMake docs propose MSVC and XCode. They also don't say how to test for it at all (CMAKE_CONFIGURATION_TYPES maybe?). Since XCode uses different targets anyway, I've limited the change to MSVC only.
> The good thing about symlinks is that we can get pretty close to what the binary sees in an actual installation
We can get there fully by creating the packed groups in the configuration specific directory instead of the toplevel build directory like we do now. But we don't actually want to get close to the actual installation, we want to work with the unpacked data directly from the repository, without having to call make every time we edit the game data. Running different code paths is unavoidable, the handful of lines of code for planet are only an insignificant part of them.
> Also, isn't it about time that we stop calling it "planet"? Maybe "game" or "data"?
The time for renaming it was when switching to HG, or when the term first became inaccurate, or with the *.oc? transition. Now it'd just churn, making everybody adjust without much benefit. Though we may want to do it when we're switching to git, hiding it in the bigger adjustments.
I also object to the inappropriate use of "when" for an event that's far from certain to happen :P
> I feel like we already did changes with more churn and less benefit.
Which ones? The *.oc? change would certainly have nicely hidden the planet->something_else transition, but other than that all changes I can recall had real benefits.
>Also, isn't it about time that we stop calling it "planet"? Maybe "game" or "data"?
When we moved from c4 to oc, the size of the repos jumped up about 100MBs (or more?). I don't want that to happen again. And 'about time', you're 8 years late...
>Also, symlink and windows?
Builtin from Vista, needs junction.exe otherwise. Works on all NTFS-Volumes.
>if you followed the tutorial in the wiki, you will have an out of tree build - nearly everyone used the tutorial to set up his environment.
Neat, I didn't think it was of use to change the target path to planet. Well, anyway, the 'work' so far is to start the cmake gui and strip the planet/ from the target path.
The simple solution is that everyone puts their CMakeCache.txt in the same folder as the CMakeLists.txt. That'll reduce the diversity of build environments and prevent future breakages. I'll start by making the tutorial say that.
Another solution would be to hardcode the path to planet in the executable, instead of looking for planet in the directory where the exe or the folder with the exe is. But I don't really want to leak the build environment into the release binaries like that.
> The occasion for me to finally change this was the recent divergence of the mac build
Care to fill me in?
> make the case of CMakeLists.txt and CMakeCache.txt in the same directory work
In what way did it not work before?
/Applications
, and there's all kind of stuff in there (some of which actually made Clonk crash due to uncaught DirectoryIterator exceptions).So the way I solved it is to either copy/pack or symlink the game data into the package. See the script.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill