My experience with scons so far is not good. Out of date and incompatible with newer versions of compilers. Work-around is painstaking to set up and requires that I manually set up the SConstruct file for my system. This of course can not be patched back since it is for my system alone. I want to start work on a cmake build system, anyone else interested post here.
Personally I'm fine with SConstruct, it works perfectly for me on my Mac/Win setup. But I do agree with you, CMake would be a great addition since it's much better maintained.
See issue #15 https://github.com/okamstudio/godot/issues/15
Build system is way too complex and migrating it at this point would take
weeks. Also, I don't like CMake, If I were to switch, I'd rather use a
build system with a real scripting language.
On Sat, Feb 15, 2014 at 12:37 AM, marynate [email protected] wrote:
Personally I'm fine with SConstruct, it works perfectly for me on my
Mac/Win setup. But I do agree with you, CMake would be a great addition
since it's much better maintained.
Reply to this email directly or view it on GitHubhttps://github.com/okamstudio/godot/issues/81#issuecomment-35146411
.
Can you provide details of what doesn't work for you?
On Sat, Feb 15, 2014 at 12:33 AM, Joshua Reisenauer <
[email protected]> wrote:
My experience with scons so far is not good. Out of date and incompatible
with newer versions of compilers. Work-around is painstaking to set up and
requires that I manually set up the SConstruct file for my system. This of
course can not be patched back since it is for my system alone. I want to
start work on a cmake build system, anyone else interested post here.
Reply to this email directly or view it on GitHubhttps://github.com/okamstudio/godot/issues/81
.
Perhaps the tutorial for scons compilation, on the wiki, is just not thorough. If this is truly the case, I welcome anyone to show me how to correctly compile using scons in windows.
I installed python 2.7 32bit, then scons 2.3. I set the environment variables and aliases for windows up. Then I did as the instructions said and ran "scons.bat bin/godot.exe" from the godot directory in C. No luck, it is not compatible with newer versions of visual studio. It could not find my VS 12 install and I had no interest in installing multiple copies of VS on my system. If you know how to get scons to recognize VS 12 then please post how to do this.
So then I did a work around with mingw. It worked like a charm after I manually modified the build file to include the correct directories for lib and header files. I should not have to do this with a build system. It should just work. If you use scons then at least include a find routine in the build system for finding the dependencies in mingw. I unfortunately do not know scons well enough to write such a routine. I deal in cmake and C mainly. Personally I don't mind using mingw, I prefer it actually. I just should not be forced to modify the build file to get it to work.
If anyone has any suggestions for making this process easier on windows then please post it in the godot wiki where it may be of use. Otherwise I will just go ahead with my own cmake write up. It will take a while, but will be worth it for more up to date windows systems.
So this is Visual Studio 13? Can you find out the version of the compiler
and linker? Run "cl" and "link" on the visual studio command prompt.
On Sat, Feb 15, 2014 at 2:10 AM, Joshua Reisenauer <[email protected]
wrote:
Perhaps the tutorial for scons compilation, on the wiki, is just not
thorough. If this is truly the case, I welcome anyone to show me how to
correctly compile using scons in windows.I installed python 2.7 32bit, then scons 2.3. I set the environment
variables and aliases for windows up. Then I did as the instructions said
and ran <> from the godot directory in C. No luck, it is not compatible
with newer versions of visual studio. It could not find my VS 12 install
and I had no interest in installing multiple copies of VS on my system. If
you know how to get scons to recognize VS 12 then please post how to do
this.So then I did a work around with mingw. It worked like a charm after I
manually modified the build file to include the correct directories for lib
and header files. I should not have to do this with a build system. It
should just work. If you use scons then at least include a find routine in
the build system for finding the dependencies in mingw. I unfortunately do
not know scons well enough to write such a routine. I deal in cmake and C
mainly. Personally I don't mind using mingw, I prefer it actually. I just
should not be forced to modify the build file to get it to work.If anyone has any suggestions for making this process easier on windows
then please post it in the godot wiki where it may be of use. Otherwise I
will just go ahead with my own cmake write up. It will take a while, but
will be worth it for more up to date windows systems.
Reply to this email directly or view it on GitHubhttps://github.com/okamstudio/godot/issues/81#issuecomment-35147759
.
No it is VS 12. The version is currently one number behind the year.
cl is version 18
link is version 12
I tested building with VS2010 and VS2013, both fine.
Have you run scons in Visual Studio command prompt?
Thanks. Can you take a screenshot of the error you get when you try to
build?
On Sat, Feb 15, 2014 at 3:25 AM, Joshua Reisenauer <[email protected]
wrote:
No it is VS 12. The version is currently one number behind the year.
cl is version 18
link is version 12
Reply to this email directly or view it on GitHubhttps://github.com/okamstudio/godot/issues/81#issuecomment-35148714
.
https://www.dropbox.com/s/z7gh87x1xshkw3h/Screenshot%202014-02-15%2001.17.11.png
https://www.dropbox.com/s/avg02kea1li8cc3/Screenshot%202014-02-15%2001.16.50.png
I followed the directions from http://www.godotengine.org/wiki/doku.php?id=compiling_windows. I first went into the command prompt from within VS then went into godot root. Then "scons bin/godot.exe" this returned the error from above picture. then I tried the batch file build mentioned at bottom of tutorial. I made the batch file and ran it from within visual studio, nothing.
Maybe you could post you're visual studio 2013 settings into an exported file. I could import that and look for any inconsistencies in my set up. Maybe it is just a matter of one setting being off within VS.
You have to run from visual studio command prompt, I'll add a screenshot to
the wiki so that step is clearer
On Sat, Feb 15, 2014 at 6:28 AM, Joshua Reisenauer <[email protected]
wrote:
https://www.dropbox.com/s/z7gh87x1xshkw3h/Screenshot%202014-02-15%2001.17.11.png
https://www.dropbox.com/s/avg02kea1li8cc3/Screenshot%202014-02-15%2001.16.50.png
I followed the directions from
http://www.godotengine.org/wiki/doku.php?id=compiling_windows. I first
went into the command prompt from within VS then went into godot root. Then
"scons bin/godot.exe" this returned the error from above picture. then I
tried the batch file build mentioned at bottom of tutorial. I made the
batch file and ran it from within visual studio, nothing.Maybe you could post you visual studio 2013 settings into an exported
file. I could import that and look for any inconsistencies in my set up.
Maybe it is just a matter of one setting being off within VS.
Reply to this email directly or view it on GitHubhttps://github.com/okamstudio/godot/issues/81#issuecomment-35151448
.
If we're going to change build systems, I'd rather it be to waf than to cmake. And @caitp seems to be working on that now, so let's wait to see how that goes.
how compatible is waf with scons?
On Sat, Feb 15, 2014 at 2:53 PM, TiZ-EX1 [email protected] wrote:
If we're going to change build systems, I'd rather it be to waf than to
cmake.
Reply to this email directly or view it on GitHubhttps://github.com/okamstudio/godot/issues/81#issuecomment-35162546
.
As caitp said in the issue you referenced, one is a fork of the other. I've never had problems building godot with scons, but waf is really slick. So if the migration to waf works out, I'm behind it, otherwise, I don't see a reason to change right now.
SCons works great for me os OSX but personally I second the opinion to have CMake only because I'd like to be able to generate XCode projects as I'm as IDE man. Any suggestions on how to generate XCode project files with SCons as the build system?
@reduz
I did run it from VS command prompt. The tools folder for VS right.
There must be some other step that is not being done. I hate learning new build systems, there is nothing more aggravating.
Are you able to run "cl" and "link" from that same command prompt?
there is nothing more aggravating.
You obviously haven't dealt with iOS signing/certificates/provisioning :p
On Sat, Feb 15, 2014 at 9:55 PM, Joshua Reisenauer <[email protected]
wrote:
@reduz https://github.com/reduz
I did run it from VS command prompt. The tools folder for VS right.
There must be some other step that is not being done. I hate learning new
build systems, there is nothing more aggravating.
Reply to this email directly or view it on GitHubhttps://github.com/okamstudio/godot/issues/81#issuecomment-35171965
.
I got it to work. I removed all posix environment folders from my $PATH. I did not know scons was posix, that definitely changes how I will use it from now on. It seems the default windows build is mingw and only when it does not find it, will it go over to VS.
@punto : You are right mobile development is the hardest
re: getting VS to work.
Visual C++ 2010 (Express):
After installing Windows SDK 7.1, select the "Windows SDK 7.1 Command Prompt"
type:
set VSINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 10.0\
That will get it past the initial problem of not being able to find Visual Studio (I also have mingw32 installed, and it will default to mingw32 if the environment variable is not found)
VSINSTALLDIR is not set by the Windows SDK 7.1 Command prompt, but is set by the vcsetvars32.bat (which is run when you select the command line for your Visual Studio version)
The next problem comes up if you have an x64 system, as the build will default to x64 using the 7.1 SDK.
You can either do:
setenv.cmd /x86
set VSINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 10.0\
And it should work fine
or you can actually fix the one file that blocks x64 from building
open up math_funcs.h
go to
#if defined(_MSC_VER) && _MSC_VER < 1800
and change this to
#if defined(_MSC_VER) && _MSC_VER < 1800 && !_WIN64
The inline assembly __asm's do not work when compiling for a x64 target
Now it will complain about lrintf() missing under VS2010 (and likely all versions prior and including 2012, this C99 function only appears in VS2013) The other option is to obviously just create 64bit assembly as the VS compiler would expect it, but this is getting beyond the problem.
The other thing that needs to change for it (assuming fixing the lrint function) is the library path
For that, I simply changed the libpaths to this in platform/windows/detect.py :
if(os.getenv("TARGET_CPU")=="x86"):
env.Append(LIBPATH=[os.getenv("WindowsSdkDir")+"/Lib"])
env.Append(LIBPATH=[VC_PATH+"/Lib"])
env.Append(LIBPATH=[DIRECTX_PATH+"/Lib/x86"])
elif(os.getenv("TARGET_CPU")=="x64"):
env.Append(LIBPATH=[os.getenv("WindowsSdkDir")+"/Lib/x64"])
env.Append(LIBPATH=[VC_PATH+"/Lib/amd64"])
env.Append(LIBPATH=[DIRECTX_PATH+"/Lib/x64"])
Again, this is assuming the Windows SDK 7.1
With VS2013 and/or Windows SDK 8.1 the above works for 64bit builds.
Please let it be CMake that wins out and not sticking with scons or WAF, what ever that is, since I can only think of one obscure project that even uses it. Use something that more people would know how to use like cmake, I would rather have anything other then WAF, even the old auto-tools or even stick with SCons.
@reduz how many projects do you know that use WAF compared to projects that use CMake?
Waf, obscure? That's cute. Autotools better than Waf? Now you're just being offensive. Here you go: https://code.google.com/p/waf/wiki/ProjectsUsingWaf
If something is working don't change it! It is more important to improve the quality of current system than make a new one. SCons is beyond from perfect, but it works.
My 5 cents:
This is only for the build scripts but it can be applied to all the code (EditorNode constructor has more than 900 lines!).
What about waf (https://code.google.com/p/waf/)
I stumbled with an article saying that waf is built from SCons but much better
Source: http://undefinedvalue.com/2008/02/19/good-bye-scons-hello-cmake
didn't realize this issue was still open. The build system was rewritten from scratch and cleaned up some months ago. It still uses SCons but it works great now.
This issue shows up as the number 4 result in a Google search for "scons visual studio". @reduz Would you mind directing future visitors to the details of the build system rewrite? Any relevant issues or pull requests? Thanks.
There already was a build system rewrite a year or so ago, but it was a
mostly cleaning up.
Scons is the best build system one can find for a project the size of
Godot, and it can also export visual studio project files already.
On Sun, Dec 20, 2015 at 5:34 AM, Jonathon Reinhart <[email protected]
wrote:
This issue shows up as the number 4 result in a Google search for "scons
visual studio" https://www.google.com/search?q=scons%20visual%20studio.
@reduz https://github.com/reduz Would you mind directing future
visitors to the details of the build system rewrite? Any relevant issues or
pull requests? Thanks.—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/81#issuecomment-166084235.
Would be awesome to integrate Hunter+Polly
https://github.com/ruslo/hunter
https://github.com/ruslo/polly
It has several packages already prepared: https://github.com/hunter-packages
Won't happen, as per the reasons given above. There is no buildsystem other than SCons (or maybe SCons-derived buildsystems like waf) that would have enough flexibility for the complexity of Godot's environment.
what if we somehow got the scons/python prople to give us a package that could run scons from a single binary on windows? Like a "scons.exe" that does everything. I think that's the main problem for us
I don't see it as a big problem; setting up a build environment on Windows is a pain anyway, so having to install Python and SCons does not seem too demanding to me after you've setup MSVC or MinGW.
On other OSes, installing scons takes half a second :)
One of the SCons devs here...if you have a real need for something like this, there is the self-contained "scons-local" package available. In addition, we have now (2.5.0+) fixed our PyPi setup, so a user should be able to simply call "pip install scons" under Python 2.7.
If you need something even simpler than that, please come over to our mailing list at [email protected] ( see http://scons.org/lists.html ) and let's discuss things.
If not totally replacing SCons with CMake, at least make both available.
CMake just require 2 clicks to set up a project on whatever IDE.
Sorry, Godot build process is way too complex for CMake. Not happening.
@reduz
conan can solve that issue. Godot will use scons, but CMake-based (not only CMake) projects will be able to import Godot modules with proper defines, link flags e.t.c.
Please look at https://github.com/godotengine/godot/issues/37180
Most helpful comment
If not totally replacing SCons with CMake, at least make both available.
CMake just require 2 clicks to set up a project on whatever IDE.