On 17 September 2010 19:56, David Gowers <[email protected]> wrote: > On Fri, Sep 17, 2010 at 1:18 PM, Seth Hetu <[email protected]> wrote: >> Currently having some trouble building this on Windows. If I just run >> scons from the root source directory, I get: >> > >> --------------------------------------------------------------------------------------- >> ...it seems to be unable to load the current revision information from >> SVN. (I am using this on a freshly checked-out source, using SVN). Any >> ideas? > > What is happening is that the 'svn' command is not found. I need to > catch WindowsError as well too, though.. so it needs a fix anyway > > (Windows behaviour WRT popen is sadly uninformative and misleading, > but I got some experience with it last week debugging jbofacki, so I > know what this kind of printout means.) > >> >> >> If I tweak the code to return a random date/revision (hooray, >> standards!) then I get: >> --------------------------------------------------------------------------------------- >> 'fbc' is not recognized as an internal or external command, >> operable program or batch file. >> > > yup, looks like path problems. As TMC pointed out, PATH needs to be > explicitly imported to make Windows happy; I didn't realize this. > > --------------------------------------------------------------------------------------- >> This is VERY odd, because if I type "fbc" in the command line, I >> immediately get Free Basic's help text. >> >> >> I tried to hack around this by manually passing the path to scons: >> scons env="PATH:%PATH%" >> ....but then I got: >> --------------------------------------------------------------------------------------- >> scons: *** Do not know how to make File target `Shared\Windows' >> (D:\visual_studio_projects\OHRRPGCE\Shared\Windows). Stop. > > what.
I think this is because Seth ran ' scons env="PATH:%PATH%" ' > I never specify any target that looks remotely like the above, > nor is it referenced in the sourcecode. <_|. > > <_< > >>_> > >> --------------------------------------------------------------------------------------- >> ...which might either be the first real error with the script, or some >> artifact from me forcing through the path/changing the SVN revision, >> etc. Better to figure out the first two first, I think. > > Thanks a lot for the feedback Seth. > > I've attached an updated SConscript which hopefully fixes these > problems (and some others that TMC noticed, thanks TMC) > > Tell me if you get the same Shared\Windows > error. (the PATH issue should definitely be fixed) > >> >> Question: can you still run the default 'clean' target? >> E.g.: >> http://www.scons.org/doc/production/HTML/scons-user/x335.html > > Yeah, I haven't disabled it or anything. > It works fine. > > (in case this appears in a double post.. this is the one with the > correct updated SConscript) I was really amazed when I ran scons... and the visual c++ commandline compiler spat back that it didn't recognise the gcc command line arguments. I'd completely forgotten I had VC++ installed (only used it once), and I certainly don't have it in my PATH. Looks like SCons' compiler autodetection is too clever. But no matter what I do, I can not get scons to use gcc instead! I've tried an awful lot of suggestions (like setting CC and CXX) I've found online and in the man page, and your tools = ['mingw'], but nothing will cause SCons to budge. In the end, I can only get past this problem by commenting out the lines to build audwrap. The good news is that once I do so, game.exe and custom.exe build! They work, except I notice that you aren't specifying the correct FBFLAGS when linking. You need to pass whatever subset of -exx -g -s gui -mt, just like when compiling each source file. This also explains why you see a warning about inconsistent multithreading options. I tried changing the backends by setting OHRGFX in my shell, and found that the script failed to rebuild modules as required (the 'semicommon' modules plus game.bas, custom.bas should be rebuilt). So I had to clean/delete build/ over and over while testing. After cleaning, I see that the order of backends in OHRGFX is ignored. The string of backends (passed to verprint) specifies not only which gfx backends to include, but also which order to try them in (specified by the order of appearance in gfx_choices). The following is unnecessary & broken (after fixing _ -> \, I get "TypeError: Command() takes exactly 4 arguments (2 given)"), so just remove it: if 'sdlpp' in used_gfx: sdlpp = Command ('cd gfx_sdl_source;make old;cd ..;cd ..') gfx_sdl.dll is provided; I can't remember, but it may not even be possible to build it with gcc. In music_map, you're using libpath instead of libpaths. allegro.bi needs to be added to standard_bi for gfx_alleg to build. music_native did not build without a little help, because audwrap/audwrap.bi includes "../lumpfile.bi", and build/lumpfile.bi was missing. However it was probably missing only because I had just deleted build/ Other than the above problems, I've tested that all of gfx_fb, gfx_sdl, gfx_directx, gfx_alleg, gfx_sdlpp, music_sdl, music_native, music_native2 link and run. Pretty good progress! Could you please check the build files into svn? Merging my changes with the new file you send every half hour is becoming pretty annoying; we have version control to handle such things. :) _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
