Ykkrosh

It still sounds like you just need to use "eselect boost" (as idle suggested), so that it symlinks /usr/include/boost to the selected version-specific directory. Have you tried that, and does it fix the problem? (As far as I'm aware this is just a Gentoo-specific issue, because it puts versions >=1.36 in slots and you have to select which one you want to use.)

Thanks! Uploaded it now. (Sorry for taking so long - had to get a new computer and copy all my old data across, before I could easily edit these things again.)

I've never noticed problems with parallel builds myself. (I've only seen the possible confusion that if one build fails, the other parallel bits carry on a little while longer before stopping.)

The server doesn't seem to be under unusual load, though there's a limit on the number of simultaneous SVN accesses and it might be hitting that - what error message do you get when it loses the connection?

If you do, make sure you provide it as a close-as-possible-to-original HTML copy, else I'll be too lazy to copy-and-paste all the text into the HTML structure

What is "0ad"? (The game currently requires the pyrogenesis_dbg executable to be run from a non-PATH-based command so it can find it from (effectively) argv[0]; if you're running it strangely then that'll fail.)

Maybe the Platform SDK setup instructions (should work with Pro too) would let you use the latest version of the SDK, which might work better? The free VC++ 2008 Express is another option that ought to work (and it can be installed alongside VC2005, though it might steal some file associations).

Hmm, looks like local.cfg isn't being handled properly on Linux. Ideally it should be in ~/.config/0ad/config/local.cfg, but as far as I can see the code just does g_VFS->Mount("config/", paths.RData()/"config");and so it only ever looks in the game's root data directory, not the per-user directory. Is that intentional, or a bug, or am I misinterpreting it?

Not the first - there's been some build system fixes from some people too

About the warnings: I agree some of them are serious, and all of them ought to be fixed - ideally we'd have zero warnings, but I added some GCC annotations recently to various functions that accept printf-style format strings, which caused all these warnings to appear.

After doing this, does the file binaries/system/libAtlasUI_dbg.so exist? It sounds like it's being compiled properly, and the problem is when trying to link against it, but I have no idea why Does anyone else on OS X have this same problem? What is the output from the commands pkg-config libxml-2.0 --libs pkg-config nspr --libs wx-config --unicode=yes --libs std,gl? The only significant difference I see from Linux is that I get g++ -o ../../../binaries/system/ActorEditor_dbg -L../../../binaries/system -L../../../binaries/system -Wl,--no-undefined -Wl,--as-needed -L"/usr/X11R6/lib" obj/ActorEditor_Debug/ActorEditor.o -Xlinker --start-group ../../../binaries/system/libAtlasObject_dbg.a ../../../binaries/system/libAtlasUI_dbg.so -Xlinker --end-group -lAtlasUI_dbg(i.e. with --start-group) but I don't see why that would matter here.

Because I didn't know it existed. Fixed the code to use it instead of yucky Boost code now

It's linking ActorEditor and ColourTester in parallel (as a consequence of using "make -j3").

Hmm... Does the file binaries/system/libAtlasUI_dbg.so exist? (or anything with a similar name?) Could you run "./update-workspaces.sh --verbose" and then "make clean" and "make ActorEditor" (without any -j option)? That should make it easier to see exactly what it's doing.

This should be fixed in r7081. (Also I've extended CxxTest so you can run "./test_dbg -test TestSysdep" and "./test_dbg -test TestSysdep::test_sys_get_executable_name" etc to run individual suites/tests, and added build system support for mock objects.) (It's not fixed very nicely, because in general it seems to be impossible (or at least extremely hard) to find an absolute path corresponding to a relative path - e.g. if I symlink /tmp/a to /tmp/b/c, then /tmp/a/../c/ is equivalent to the absolute path /tmp/b/c/, so you have to mess around with the filesystem just to normalise the path. It would be much easier if we didn't actually try to determine an absolute path for the executable, and were happy with unnormalised relative-to-cwd paths, but I don't know if we can cope with that.)

Whoops, "osx" vs "macosx" was my mistake - fixed now (I hope). Sounds like AtlasUI failed to compile, so there must have been another error somewhere. Do you still get the problem if you do "make clean" and then a normal "make" again? If so, what's the output when you run "make AtlasUI" (which hopefully will mention the error)?

Oops, I'd completely forgotten about that. Seems like defining _REENTRANT manually is a sensible thing to do, so I've committed that change now, so hopefully it'll work

I think the incompatibility with -Wl,--as-needed should be fixed now (r7077), and hopefully any other issues about linker argument order, thanks to idl0r . (But let me know if these changes break anything!)

Could you look in /usr/include/libxml2/libxml/xmlversion.h (I'm assuming it's the same path on OS X) for the block of code that sets LIBXML_THREAD_ENABLED? We use libxml2 in multiple threads simultaneously, so it really needs to have been compiled with LIBXML_THREAD_ENABLED (else it uses some per-process global data structures, if I remember correctly). Our code doesn't directly depend on that flag, but it checks to make sure libxml2 was compiled properly.

It sounds like you might be viewing an old cached version of the page - try holding 'shift' while pressing your browser's refresh button and it should hopefully get the newest version (which does have all the flags on all the pages).

Thanks for these! I've added both to the site, and hopefully didn't make any terrible mistakes (inappropriate flags, incorrect text, mixed up the two languages, etc) The easiest thing for me is if you use "view source" on the English page to see the original HTML, then edit the text in there, then post the new HTML code (in the forum as plain text, or as an attachment, or anything). Otherwise I have to manually copy the text into the HTML page myself, which is fine but takes a bit of time

It turns out that if nobody has op privileges on an unregistered QuakeNet IRC channel for a while, then anybody can automatically request ops and take control of the channel. That happened in #wfg, and the people with ops are messing about and talking Finnish and generally not participating in useful game development discussions. So, new IRC channel: #0ad on QuakeNet. (It's registered with the Q bot so we can keep control of it.)

That's pretty much what I suggested here - seems like the proper way to do installation of the game. But there's still the issue that during development we want to run the game directly from the SVN directory with no installation, so it still needs to be able to cope with relative paths as well as installed absolute paths. We do have a couple of dynamic libraries (the Atlas editor UI, and the Collada parser) that are loaded on-demand at run-time, and I'd be happier not to change it to be monolithic, but I think it shouldn't be much of a problem anyway. Binary packages are configured and compiled for a particular Linux distribution with a particular filesystem layout. With most programs you can change the default directories by passing arguments to the ./configure script before you run make, and the paths get compiled into the executable. You can't change the paths without recompiling, but you never need to change the paths so that's okay. I don't see any reason not to do the same - so we should let people specify the paths (for system data, not per-user data) when calling update-workspaces.sh, and default to the common /usr/... paths, and then the game can use those string constants when loading data and libraries (when it's run in the run-from-system-installation mode, not the run-from-SVN-checkout-directory mode).

I don't care much about philosophy, I just want things to work properly . I'm happy as long as the output is sensible. Surely we can just tell it? We know that most low-level errors are always bad and should be reported in ugly dialog boxes. We also know that if config/default.cfg doesn't exist then it's a serious error and should be reported seriously, but if config/local.cfg doesn't exist then it's harmless and intentional and we should do nothing more than print a note in the log file, but if e.g. we get ENOMEM when looking at local.cfg then it's unexpected and should be reported seriously. So we need to encode that knowledge in the game code, and make sure the filesystem code acts consistently with the desired behaviour.The GetFileInfo(...) == ERR::VFS_FILE_NOT_FOUND thing was a hack to achieve that behaviour (by using a function that doesn't immediately raise ugly dialog boxes when the file is not found, before using the file-opening function that does). If GetFileInfo will always either return FILE_NOT_FOUND or raise an ugly dialog box itself, then that's okay, but I don't want it to silently ignore any other errors; and it looks like GetFileInfo doesn't do that, and the new code looks like it will silently ignore the other errors. (Actually it should be changed to only do the file-not-found check on config files that are meant to be optional, like local.cfg, but that's a separate issue.) Yep, I couldn't see a way to do so with the boost filesystem API - create_directory lacks a mode_t parameter ... We should revert to calling mkdir then, eh?That Boost behaviour sounds like a bit of a pain, and I don't see any way around it. (umask could work but it's seemingly not thread-safe so it's probably too dangerous.) Yeah, I'm kind of worried about confusion regarding profiles etc., especially because the old location is still supported (depending on cmdline args). Do you have any ideas?Write a test which creates an empty directory, sets $HOME to it, then runs InitVfs (suitably refactored to be testable) and writes some files and then checks the test directory contains all the right files in the right locations with the right permissions? (and then repeat for the other cmdline-dependent mode, and then ideally test edge cases and error handling)

Something that interests me: This seems to be the first time they've mentioned "WebGL" (standardisation of Mozilla's work on letting web pages use a JavaScript API to access OpenGL ES 2.0, i.e. for drawing fast 3D stuff in web browsers (without plugins)).