I’ve been trying to compile for days now, finally got it working by following instructions here and in compiling.md and on reddit…basically a wild goose chase that finally paid off. I’ve got the code:blocks 13.12, mingw 5.2 and I can compile and run the curses version with changes I’ve made and it works perfectly. However, I can ONLY compile the curses version. Selecting the “Release (SDL, loc, lua, Sound)” from Project -> Build Options only compiles the curses version. I’m not sure what I’m doing wrong here, but I’d really like to compile the tiles version. Any suggestions would be appreciated.
Edit: So…yeah I’m a dumbass. I found the correct place to choose which type of build. Build -> Select Target…There’s also a big obvious dropdown box…
Now it’s asking for SDL.h and failing immediately. Yay, progress!
edit2: Ok, found SDL.h in the Windepend\include\sdl2 directory. So I added that to the search directory tab of Release (SDL, sound) and it’s happily chugging away again…I don’t understand the error I get when I tried to build the Release (SDL, loc, lua, sound), it says lua5.1 ‘command not found’ or something like that. But if I can get tiles working in any form I’ll be quite pleased.
Edit3: I’ve got tiles working, woot! Will the lack of lua cause me any trouble? I know most of the black list stuff uses lua, is that what that function supports? And if it is, how do I get past the lua5.1 error I mentioned above? I’m going to bed now, I hope someone can help me out with this sometime today. Thanks
edit4: it helps to actually have lua installed when trying to compile with lua enabled…
Well…hmm. I never got that far with using the stuff you sent me in a PM, as I kinda wasn’t sure how to make use of any of it, and as it was for 64-bit Windows, and mine is 32-bit.
So, I’m back to looking at the instructions for MinGW in COMPILING.md. I’ll review the instructions and try to see if I can figure out what the fuck I’m doing.
Two big sticking points though.
#### Bundled Libraries
The following archives were pre-bundled for convienience and reduction of head-aches, simply download and extract directly to the root directory of the CDDA source:
* `64-bit SDL \ Tiles \ Sound \ Lua \ Localization` http://dev.narc.ro/cataclysm/cdda-win64-codeblocks.7z
First, how am I expected to repeatedly compile-test something if I have to drop this into the actual directory for the CDDA source? I’ll have to move the archives back out before making any changes and committing them. Alternatively, I’d have to copy the entire massive archive so that Github won’t attempt to commit the additional files?
Second, where we go again with the 64-bit issues. How am I to be sure that this will work with 32-bit?
You don’t need to move things out of the directory before compiling, the compiler knows what it needs. Git seems to expect these files to be present and doesn’t try adding them to the repository when you commit. I just unzipped that file into Cataclsym-DDA and never looked back. I had to add sdl2 to the search directories to make it work, but I’ve since been told I could move the sdl2 includes into one of the directories it searches in by default and not need to change the codeblocks project file.
As far as the 64/32 issue, you could go a couple ways. Try it and see OR hunt the includes down in their 32-bit versions.
I believe the full list of needed includes is there in compiling.md, the bundle is just there for convenience. Just remember this one thing: Your repository is hosted on github, so if you break the local copy, just delete it and restore from either github or a second copy on your machine. You can’t lose anything important, so don’t stress over breaking something while you are trying to get it to compile.
These seemed to be the most important libraries to have from windows MinGW guide in compiling.md:
Hmm. Then again, it seems I don’t need to dump these files into the directory if I just want a quick compile without tiles or localization.
That said, the reason I don’t want to break the local copy is because restoring it further slows down the cycle of fixing things. That said…still have other concerns about the entire idea.
And then there's the other issue. Given all the jokes I crack about the source code melting when I so much as look at it, it should be apparent that I inevitably tend to make some sort of mistake, and wind up at a complete loss for what I'm even doing wrong. If it's committed to the pull request, at least then others can look at it and find the predictable amateur fuckup that I completely failed to notice.
If I’m instead compile-testing it and not committing it, others can’t actually look at my work, meaning I have to go and ask for help, then provide code excerpts of what all I’m doing when I eventually hit a problem and have no idea what I’m doing.
And even then, there’s the possibility that when I post what I’m doing, I might miss important information in other files that might be the cause of the problem. And if I’m at the point where I don’t know WHERE the problem is, it’s rather obviously harder to provide those code excerpts, specifically excerpts that would actually reveal what part I fucked up.
It just gets irksome when I try to compile-test, fail to manage it, and then start seeing multiple reasons why the lazy route of using Jently as an error-checker is more efficient. Then eventually people complain about my laziness and berate me over it, and I start wondering why I even bother doing anything.
If no errors pop up in the first 20 seconds or so, I go grab some coffee or watch some youtube…
If you’re still editing in notepad++ and compiling from the command line…good luck, have fun. You aren’t doing yourself any favors. Try codeblocks, it’s waaay better than notepad++ for editing the source, the repository even has a codeblocks project file included. A project file for SublimeText is in there as well, though I haven’t done anything with it as of yet. Either one > notepad++ for coding. Notepad++ is awesome for editing json’s but it leaves a lot to be desired when you are editing source and the function you are playing with is spread across half a dozen files.
Cue everybody with a difference of opinion on what method is the best…I condone this one bc it’s what I could get working after all kinds of frustration trying other methods.
Heh. I never had any luck with Code::Blocks though. >.<
But if it takes you long enough that a coffee break is in order, that makes it sound like more time wasted than ye olde “make Jently do it” method, at least when the bot isn’t bogged down.
Which makes me continue to question everyone’s insistence that compile-testing is somehow faster.
Sorry, I wasn’t clear, that coffee break is for a total project rebuild of SDL, it takes about 20 minutes, and I perform one after I pull a bunch of changes from upstream. When I was testing fixes for the Adrenaline pump mess, it took about 20 seconds, because it only had to build the .cpp file I was poking at. It took about a minute after I added a new function to a .h file. And it was all right at my fingertips with instant feedback when I broke something and it couldn’t compile.
That’s what people mean by saying compile-testing is faster. Just knowing that what you commit WILL compile is a big help, whether or not it’s the correct solution to the issue.
Believe me dragon, I understand your frustration, but this is really the fastest way to test things once you get it running properly. From my limited understanding, changing *.h files is generally slower than changing *.cpp, something to do with #include statements. But it’s all faster than typing it up in notepad++, copy pasting it into your repository, commiting, waiting for jently, digging through jently error report to find the problem, making a change in your web browser, waiting for jently, etc…
What issues did you have with codeblocks? It was pretty plug and play for me
Installing codeblocks is literally just next->next->next.
Codeblocks uses MinGW and a more modern one than the default one on MinGW site at that.
Does anyone here use Codeblocks? Is at simple as opening the project and selecting build or are there extra steps?
Maybe the guide should start with that. It doesn’t make sense for the guide to tell you to compile tiles+localization+sounds+gentoo right away, it should start with console build with no bells or whistles.
I think it should compile the no frills cata straight out of the box, just as you described. I never tried, but the build settings in the project file are mostly blank. I can’t speak for the version of mingw it contains, I upgraded to 5.1 immediately
Getting lua and sdl working was a chore, but that was mostly due to the guide being out of date and kind of vague. And the codeblocks project file doesn’t match the ‘convenient libraries’ file, the compiler won’t be able to find the sdl libraries without adding sdl’s directory to the ‘search directories’ tab or unzipping all the libraries in the directory it searches.
I did some testing on freshly installed codeblocks:
Codeblocks 13.12 ships with gcc 32-bit version 4.7. Cataclysm needs, at minimum, gcc 32-bit version 4.8 to compile. GCC 64-bit version 5.1.0 is what I use, and it works just fine. Using an updated mingw with sdl2 libraries moved into /windepend/include and using the default settings in the codeblocks project will compile a release build with all the frills perfectly. The sdl2 and lua libraries don’t matter for the no-frills curses build, but the compiler still needs to be updated for cata to build properly.
I can successfully compile simple curses build with Code::Blocks, but anything else is giving me errors. I got all the libs for SDL, lua etc in WinDepend folder with include and lib subfolders. I put it in Cata source folder. All compiler settings, linker settings and search directories setting seem to be correct, but…
When I’m trying to compile with SDL, it barks "WinDepend\include\SDL2\SDL_platform.h|121|fatal error: winapifamily.h: No such file or directory|’"
When I’m trying to compile with lua, it barks “‘lua5.1’ command not found!”.
Edit: after scanning compiling.md I found that I should replace SDL_platform.h. It worked, but now I got numerous errors “obj\ReleaseSDL\src\cata_tiles.o:cata_tiles.cpp|| undefined reference to `SDL_RenderFillRect’|” and the like.
I can only speak to the lua component of your problems, I don’t know how to resolve the other two. Compiling.md is notoriously out of date though, so reverting to the original SDL_platform.h and fixing it from there may be a place to start.
“‘lua5.1’ command not found!” means one of at least two things:
Lua5.1 hasn’t been installed on your system. This can mean either you haven’t installed lua or you’ve installed the wrong version, codeblocks is looking for “lua5.1.exe” when it tries to run the script.
Lua5.1 is installed, but isn’t included in your systems PATH variable. You will need to add the exact directory location of the lua5.1 installation to your the PATH system variable on your PC, there are a few references to how to accomplish this in the toolbox and google is an excellent source as well, try “editing windows (version) path variable” as a place to start.
I have lua 5.1 installed and it is included in PATH. But, it’s executive is lua.exe, not lua5.1.exe. When I manually renamed lua.exe to lua5.1.exe, it started compiling, but I got errors like “obj\ReleaseLua\src\catalua.o:catalua.cpp|| undefined reference to `lua_tointegerx’|”.
Seems to be a possible issue with the lua version used? Are you positive you are using lua 5.1 and not 5.2? I’ll admit I haven’t compiled from source in about 3 weeks, perhaps something has changed recently. It was pure luck I even happened to be online tonight due to insomnia…
It seems that I solved my Lua issue. I downloaded the latest version (5.3.2) of Lua from lua.org and compiled it using msys. Then I linked linker settings and search directories in C::B to directory with my compiled lua.
But now it’ giving me some strange error “obj\Release\src\crafting.o:crafting.cpp|| undefined reference to `player::gunmod_remove(item&, item&)’|”.
