For$
<!-- begin site header -->
<div id=

Author Topic: Unified building  (Read 12952 times)

krono

  • Newbie
  • *
  • Posts: 6
    • View Profile
Unified building
« on: January 14, 2011, 03:48:08 pm »
Dear all,

currently, there are three building systems:

  • Visual Studio
  • Makefile
  • CMake

Interestingly, the last one is capable of generating the both above.
(see http://stackoverflow.com/questions/395169/using-cmake-to-generate-visual-studio-c-project-files)

Please, is it possible to focus on one, preferably a portable, build system?

so Long,
    -krono

xoft

  • Newbie
  • *
  • Posts: 42
    • View Profile
Re: Unified building
« Reply #1 on: March 06, 2011, 12:57:54 am »
I second this request, as I'm using the (officially unsupported) VS2008 Express to build MineServer and it keeps getting more and more difficult with each source update.

Alas, the CMake files are broken at the moment, at least for windows / msvc builds and I have yet to find a fix. Down to the last linker error ;)

Jailout2000

  • Newbie
  • *
  • Posts: 49
  • Enthusiast
    • View Profile
    • My Website
Re: Unified building
« Reply #2 on: March 06, 2011, 01:43:26 am »
I'm using the (officially unsupported) VS2008 Express to build MineServer and it keeps getting more and more difficult with each source update.
I just use the do_build.bat file; it never generates errors for me unless they make a major change in the file structures. I can even include plugins and such. However, it does generate warnings, mostly when it detects lossy conversions (int to byte, etc.).

Anyways, I like the idea as well, but whatever is chosen needs to be easy to work with across all platforms. I haven't been able to get anything except VS2010's tools to work on Windows.

Visit my website to see what's up with me.

xoft

  • Newbie
  • *
  • Posts: 42
    • View Profile
Re: Unified building
« Reply #3 on: March 06, 2011, 02:53:27 am »
As I wrote in another post, using a BAT file to compile using MSVC is a very bad idea - you'll miss all the debugging info, runtime warnings, such as unassigned variables, asserts etc. It is good enough if you want to compile MS for yourself; it's useless if you want to develop. A project file is the only way to go.

I managed to fix up CMakeLists.txt for use with MSVC2008 - now it generates proper project files for the main exe and the plugins; though the output paths may still need some tweaking ($/files/Debug, $/files/Release). Since I'm not yet friends with Git, I'll try attaching a diff file to this thread so that anyone interested can try and review it.

I think CMakeLists is well suited for MineServer, it seems simple enough that even I managed to learn to hack it within a few hours, and it's being done already, more or less.

On a similar note, the wiki needs serious care with windows compiling. If my CMakeLists patch (or a derivative that works) gets into the main source tree, I can write something up.

Delirium

  • Newbie
  • *
  • Posts: 27
    • View Profile
Re: Unified building
« Reply #4 on: March 06, 2011, 12:01:59 pm »
Well, I think it shoud be left to the end user which build system he use. I think Visual Studio fits best for windows users, and there should be the project map for visual studio. Thats also good for plugin developers as developing plugins is very simple with that IDE.
Make it idiot proof and someone will make a better idiot.

xoft

  • Newbie
  • *
  • Posts: 42
    • View Profile
Re: Unified building
« Reply #5 on: March 06, 2011, 01:11:44 pm »
... it shoud be left to the end user ...

Exactly. And that's why something like CMake is great - it can create Visual Studio projects for people with Visual Studio, or Code::Blocks workspace for those in love with Code::Blocks. Eclipsists will get their Eclipse projects as well. And the list goes on. And in the meantime, the developers only need to change one "super-project" when they add / remove / rename a file and the change gets into all the generated project files.

I have to say I was first sceptic about using CMake, seeing that the primary source of information on the system was a book they were too happy to sell. But I can see the benefit and having actually edited the CMake project, I think it's worth it.

krono

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: Unified building
« Reply #6 on: March 06, 2011, 01:30:17 pm »
After All, keeping a CMake-project up-to-date helps to
keep mineserver portable.

Yes, most of you probably use VS, But _which version_
And, the Unix-Guys?

I don't like CMake that much, but it is the best portable
compromise, I think.

winex

  • Newbie
  • *
  • Posts: 7
    • View Profile
Re: Unified building
« Reply #7 on: March 08, 2011, 12:09:11 am »
xoft,
thx for trying this, i couldn't convince Fador to try :(

mineserver doesn't have this dir:
Code: [Select]
+ include_directories(${PROJECT_SOURCE_DIR}/include)
i'm curious if we need winmm.lib at all, can you check w/o it plz?
Code: [Select]
+ link_libraries(ws2_32.lib winmm.lib)it sounds weird to be dependent on multimedia library :P

files/ wasn't mentioned to be output dir, so:
https://github.com/winex/mineserver/commit/6e193faf5fdc790eaa6b24aab5a7aff9e2b5a185

hope this helps...

edit: removed merge-commit from my branch, so commit sha has changed
« Last Edit: March 08, 2011, 01:23:06 am by winex »

xoft

  • Newbie
  • *
  • Posts: 42
    • View Profile
Re: Unified building
« Reply #8 on: March 08, 2011, 10:59:11 am »
mineserver doesn't have this dir:
Code: [Select]
+ include_directories(${PROJECT_SOURCE_DIR}/include)

The include dir comes from Fador's MSVC build pack (libnoise, libevent and libcurses headers in $/include, respective libs in $/lib), which is needed for any MSVC build, not only for 2010 (and is in fact compatible with MSVC 2008, I'm using that for building).
If there's someone skilled in CMake, they might add a check for this "dependency"

i'm curious if we need winmm.lib at all, can you check w/o it plz?
Code: [Select]
+ link_libraries(ws2_32.lib winmm.lib)it sounds weird to be dependent on multimedia library :P

winmm.lib is needed for high-precision timer (function timeGetTime() ) - my linker was complaining about that function missing, luckily I remembered it's part of MM library.
It should be pretty straightforward to rewrite that part of code not to use WinMM (it's only timing information for logging purposes, after all).

xoft

  • Newbie
  • *
  • Posts: 42
    • View Profile
Re: Unified building
« Reply #9 on: March 11, 2011, 07:32:32 pm »
Okay, we're almost there, but not yet :)

The include dir needs to be set for individual plugins as well - some of them use stdint.h, which is not in MSVC, so we need to point the compiler into the build pack

Also, $mineserver_depends CMake var doesn't seem to do anything with regards to input libraries for the linker - adding ws2_32 and winmm into the var doesn't include them for linking in the VS project file. We really need to do a
Code: [Select]
link_libraries(ws2_32.lib winmm.lib)
for Win32 platform

winex

  • Newbie
  • *
  • Posts: 7
    • View Profile
Re: Unified building
« Reply #10 on: March 13, 2011, 12:10:17 am »
oh, sorry, my bad...

we don't use find_package() or w/e for this, so i missed to look at how it is actually being added!
here is the fix:
https://github.com/winex/mineserver/commit/10088b51c1a2653d65ed60ce632f5c7b70f8d861

btw, link_libraries() is deprecated, we're using target_link_libraries()


about includes:
you should setup some directories like *nix systems have by default: /usr/include and /usr/lib
for development with all your (libs/headers) and specify that to cmake or change Find*.cmake modules to find that.

iirc, there were some environment variables pointing where your libs are located for M$ compilers.

installing dependencies locally for every project isn't a good idea for most uses.

lol @ stdint.h... maybe there is C++ analog and msvc has it? idk.

xoft

  • Newbie
  • *
  • Posts: 42
    • View Profile
Re: Unified building
« Reply #11 on: March 14, 2011, 01:12:17 pm »
ad includes:
For linux, single include / lib dir makes sense, because noone really uses any other compiler than gcc.
For windows, where there's thousands of compilers, each binary-incompatible with the others, such a "repository" is a no-go, libs from one compiler cannot be used by the other, so it's actually better to make libraries project-local.
Not to mention versioning, which is zeroish for windows.

winex

  • Newbie
  • *
  • Posts: 7
    • View Profile
Re: Unified building
« Reply #12 on: March 14, 2011, 08:22:43 pm »
it can't be binary incompatible since you're building for the platform.

and that windows-development-hell is your decision, so nobody else cares about it. :P