click

Hi everyone! We're looking for new developers to assist with enhancing TrinityCore with proper SOAP/REST-based webservice-support - there's no pay, but a lot of glory! People that wants to get involved will get : *) a free copy of the TrinityCore sourcecode (available on GitHub, all yours for the picking!) *) opportunities to swear at the other devs in our IRC developers-channel (who doesn't want to do this?) *) lots of gray hair (unless hairless, like me) *) your code inside one of the most fun codebases to work on What we're aiming for: *) To actually start using the gSoap-library we've got in the sourcetree for something else than just being a mediator between executeCommand and prettified XML output. *) Exposing more functions to the public than is currently done - we have _1_ (one) function active per today - we're really awesome-sauce aren't we? Some minor, but important, requirements: *) You need to know how to code in C++. *) You need to understand how SOAP/REST works. *) You need to have a keen eye for details to avoid doing the same funny/silly/scary/whatever mistakes that the rest of us do all the time... If YOU want to assist in creating this, please give us a note here on the forums, or on IRC for those of you wandering by there!

diff --git a/CMakeLists.txt b/CMakeLists.txt index 5335207..f01b21e 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -13,7 +13,11 @@ project(TrinityCore) # CMake policies (can not be handled elsewhere) cmake_minimum_required(VERSION 2.8) -cmake_policy(SET CMP0005 OLD) + +# add this options before PROJECT keyword +set(CMAKE_DISABLE_SOURCE_CHANGES ON) +set(CMAKE_DISABLE_IN_SOURCE_BUILD ON) + # Set RPATH-handing (CMake parameters) set(CMAKE_SKIP_BUILD_RPATH 0) That SHOULD make the error occur on 2.8.x, and thus verify my theory on the subject.

+Spp : Do you have any specific reasoning behind removing the cmake macro for OpenSSL-handling? And, why are you rewriting the PCH-system? PCH-headers including the .cpp header into a predefined object (gch-file) adds another useless file for gcc-based compilations, and the earlier version worked totally fine. This ALSO destroys clusterbased compilation, since the gch-file is NEVER propagated to the external host systems. Which means that IF my buildbotsystem would use the PCH-system, it would fuck up, as the GCH-file is local, and not propagated to the cluster-compilers. This would then add load to the LOCAL system on a massive amount each time something was/is/will be pushed into the repository. All you would have needed to do would be to add the correct testcase for clang, and adjust the macro accordingly - it has worked flawless for years. Now, to the main issue : why the HELL are you removing GCC-specific compileflags allowing debugging to be done properly under GDB3? This is not something that you or anyone else should nilly-willy do without discussing it here first. Some info: -ggdb : Produce debugging information for use by GDB. This means to use the most expressive format available (DWARF 2, stabs, or the native format if neither of those are supported), including GDB extensions if at all possible. vs -g3 : Level 3 includes extra information, such as all the macro definitions present in the program. Some debuggers support macro expansion when you use -g3. These two are NOT EQUAL, and removes specific GDB3-tagging in the binary - basically, you're fucking up gdb debugging, which is the standard debugger for *nix-based platforms If clang fails using it, tough luck, define it different for clang through the cmake/compiler/* definitions per compiler, and EXPLICITLY test if you're under clang. Also, the full removal of xcode is not even discussed - if you've got a problem with supporting xcode, take it here. Now, the last part that I really want to air out : why the hell are you removing the -fno-delete-null-pointer-checks parameter? That is there for a purpose, namely to allow NP-bugs to be properly debugged and checked. -fdelete-null-pointer-checks Assume that programs cannot safely dereference null pointers, and that no code or data elemet resides there. This enables simple constant folding optimizations at all optimization levels. In addition, other optimization passes in GCC use this flag to control global dataflow analyses that eliminate useless checks for null pointers; these assume that if a pointer is checked after it has already been dereferenced, it cannot be null. Note however that in some environments this assumption is not true. Use -fno-delete-null-pointer-checks to disable this optimization for programs that depend on that behavior. Some targets, especially embedded ones, disable this option at all levels. Otherwise it is enabled at all levels: -O0, -O1, -O2, -O3, -Os. Passes that use the information are enabled independently at different optimization levels. Short story: Don't fuck around with the buildsystem unless you know EXPLICITLY how and why things are done the way they are. If something is unclear, poke me about it.

@paradox: yes, i am and i will be like that in the future as well : it's NOT our problem if people fuck around with custom codebases (aka NOT THE OFFICIAL SOURCETREE) and no, we do not use git_id or the likes, we actually poll git (the program) directly.

sql/updates/world ... see the sql-files there? you might want to use them...

Just compiled it, extracted data from base blizzard data (had all the needed files uploaded to the server), and extracted. Works like it should. [click@ice ~/dev/wow/tc]$ cat /etc/debian_version 6.0.4[/code]

Care to post the complete output from CMake during configurationphase, please?

Erm, ok? One note here, since libmpq requires both the libbz2-library and zlib-library objects to already exist before it will do anything... The entire linking is controlled by the sequence given in the original file, meaning libmpq will be linked in AFTER the other two has been compiled/linked in, and thus allowing for libMPQ itself to find the requested functions. Why this alledgedly happens for you beats me, but for the sake of it, post the parameters you use for make during compilation (that means -j flags and whatnot). I can't see the reason for moving libMPQ -up- in the chain, it kind of counters the entire link-sequence. Unless they changed CMake somewhere and never posted it in their changelogs... (Also, supply the entire cmake-configuration phase output so I can see where CMake actually grabs the headers from - it might be that it finds something you've installed locally, ie. not systemwide).

As I said in the previous thread: REGENERATE THE PROJECT FILES WITH CMAKE. If you really need help to understand that, I suggest you read the wiki : http://www.trinitycore.info/ - read the Windows-part there. Thank you.

--- Canned message start It appears the issue in the original post was solved, so this thread shall be closed. Should you encounter any other difficulties, please open a new thread. --- Canned message end ---

rebuild projectfiles with cmake - those files were nuked/removed and replaced with another one.

[ERROR]: In mysql_stmt_prepare() id: 30, sql: "SELECT arenaTeamId, weekGames, seasonGames, seasonWins, personalRating FROM arena_team_member WHERE guid = ?" [ERROR]: Unknown column 'personalRating' in 'field list' [ERROR]: In mysql_stmt_prepare() id: 172, sql: "UPDATE arena_team_member SET personalRating = ?, weekGames = ?, weekWins = ?, seasonGames = ?, seasonWins = ? WHERE arenaTeamId = ? AND guid = ?" [ERROR]: Unknown column 'personalRating' in 'field list' [/code] Your database is not up to date.

--- Canned message start It appears the issue in the original post was solved, so this thread shall be closed. Should you encounter any other difficulties, please open a new thread. --- Canned message end ---

That is a G3D-library issue, and known - there are a few hints out on the net on fixing that part.

If you are able to, please drop by on IRC: irc.rizon.net #trinity or go to http://www.rizon.net/index.php?do=chat to use a web-based IRC-client. And also, erase and recreate the build-dir, then try again with the previous setting.