Jump to content

daniel.santos

Community Newbie
  • Posts

    2
  • Joined

  • Last visited

daniel.santos's Achievements

Tiro

Tiro (1/14)

0

Reputation

  1. Hello guys, very cool game! This is my first posting and I'll bet you've heard this suggestion before. First off, I know the common response (certainly from me on my projects) when somebody has a suggestion like this is "Sounds great! When will you have it done? " Unfortunately, I don't have the time to work on 0ad, sorry. None the less, there are certain traditional mechanisms used in *nix (Linux / UNIX) build systems that are generally followed 1.) Allow your build system to manage your configuration, never use shell scripts. While it's occasionally hard to avoid custom scripts, the modern build systems (autotools, CMake, etc.) can do almost everything that needs to be done on their own, given proper input files. On almost all projects, I can do my configure & build from a directory other than the one I checked out, leaving it's contents completely unmodified. But the major advantage is that I can do it in a tempfs filesystem -- this means no disk writes are needed for the build and it's much faster. In fact, by the time I build it a second time (say, I've made a change somewhere), all of my source files will be in the Kernel's page cache, so there wont even be any disk reads! 2.) Don't include binaries in your source tree. Linux users (especially Gentoo-ers) are especially wary of pre-built binaries. While I know that it's often useful and quite handy to have binaries included, it's fairly untraditional. I'm not sure what to propose for this because I'm very new to your system, but some optional mechanism would probably nice. Also, most game projects keep their game data in it's own directory. Often, this is what you'll see: data docs src (README.txt, configure.ac, CMake.txt, Makefile.in, etc.) 3.) Allow the user to build against their own libraries. Maybe this goes with the above item. In fact, on my OS (Gentoo Linux) the only packages (ebuilds) that I don't have access to is nvtt and fcollada and I already had all of the remaining libraries installed except for spidermonkey and enet. Plus (back to item 1) standard build system will allow the person configuring to choose where their libraries are located, in case they wanted to link against yours, or even against a special modified version of them. So again, probably better if checking out this tree was optional as well, especially at a whopping 850MB! 4.) Build system should allow the choice between static & dynamic linking. While operating system kernels now all memmap executables, thereby not using up memory that's unneeded, it's still a nice thing to allow. The area where this is (oddly) begging to become antiquated is with link-time optimizations. MSVC has had this for a little while now and gcc is finally getting them with 4.7 (you can get them in gcc-4.6 if you enable them in gcc's configure, but they are still very experimental). But projects like LLVM again makes this static linking unnecessary for obtaining these optimizations. Of course, it's even better if you can adhere to one platform's standards using a mechanism or idiom that meshes nicely with both your project's and the standards of other platforms as well. Anyway, I gotta run so I'll check back later. I know there was a few other items that I've forgotten to mention.
  2. ../../../source/lib/allocators/headerless.cpp:757: error: attributes are not allowed on a function-definition My understanding of __attribute__ (nothrow) is that it is an optimization feature to prevent the compiler from generating unwind code. I would recommend consulting an expert on this, but I believe the c++ throw() clause will accomplish the same thing (as in MSVC) and you can (and actually, must) stick it on both the declaration and the definition, whereas gcc only accepts the attribute on the definition. See http://gcc.gnu.org/o...Attributes.html for the vague details. --- lib/code_annotation.h (revision 10384) +++ lib/code_annotation.h (working copy) @@ -63,7 +63,8 @@ * smaller and more efficient code. **/ #if GCC_VERSION >= 303 -# define NOTHROW __attribute__((nothrow)) +//# define NOTHROW __attribute__((nothrow)) +# define NOTHROW throw() // special meaning, equivalent to __declspec(nothrow) #elif MSC_VERSION # define NOTHROW throw() // special meaning, equivalent to __declspec(nothrow) #else Alternately, you can make a separate macros for the declaration & definition.
×
×
  • Create New...