Which development tools do you use?

[SupSuper]

This is to assess what development tools do contributors use and which should we focus on supporting in the codebase. If you use multiple, just vote for the one you use most with OpenXcom. No religious wars!

Don't worry, dropped tools will still be supported, we just won't maintain files for them in the codebase anymore so you'll have to generate them with CMake or make your own.

[Yankes]

Eclipse? I only know this as editor not compiler.
as for compiler I use MinGW for openXcom

[Ninetailed]

Eclipse? I only know this as editor not compiler.
as for compiler I use MinGW for openXcom

It's both. Eclipse is a complete IDE; each programming language it supports (C family, Java, etc.) comes with its own, Eclipse-specific compiler. The idea behind this is to provide hooks for Eclipse's debugger and to support incremental compilation as changes to the source files are made, as well as a host of other, minor concessions to Eclipse's interface.

I don't know how well it holds up compiling OpenXcom; I haven't tried. But I do use Eclipse in work and know it fairly well.

[Yankes]

It's both. Eclipse is a complete IDE; each programming language it supports (C family, Java, etc.) comes with its own, Eclipse-specific compiler.

Its first time I head about this, in my case its use MinGW GCC (or Cygwin GCC).

[luciderous]

Technically, the question us about IDEs, not compilers per se.
I use Xcode with Clang/LLVM as a compiler.

[grrussel]

Clang, and the Makefile, on OSX - notably, gcc/g++ will not be the OSX compiler in future. At the moment, clang++ is a direct replacement for g++ in the makefile.

https://bitbucket.org/grrussel/openxcomosx/src/959b3efb5e0a/2011-11-02-23-48/build_log.txt

[DaiShiva]

I use visual studio as my primary IDE but at work I have to compile the same codebase on win32, mac, linux and solaris, so CMake is my preferred tool of choice.

[borfast]

Hmmm... I believe you're mixing compilers with IDEs and build tools...

• Visual Studio is both a compiler and an IDE, so that one's fine.
• MingW is not a compiler itself (it's a development environment for Windows and uses GCC/G++ as a compiler) but it is different enough to stand alone;
• Code::Blocks is an IDE and it supports multiple compilers;
• Eclipse is also an IDE and its CDT (C/C++ Development Tooling) project uses GCC/G++ as the compilers;
• Xcode is also an IDE and it uses either GCC or LLVM as a compiler;
• Makefile is neither a compiler or a IDE; it's a file that needs to be generated specifically for a platform (OS and compiler) and describes the build process, which is then carried out by Make, which is also not a compiler, just a tool that, among other things, executes the compiler when needed;
• CMake, putting it simply, is a tool to generate Makefiles and other types of "guidance" files for compilers, be it GCC/Makefiles, Xcode or Visual Studio;
• Autotools is a set of tools (Autoconf, Automake, and Libtool) that do a bunch of stuff to aid a compiler, but they don't include a compiler.

So if you're really interested in knowing about the compiler, the poll choices boil down to

• Visual Studio (which is really not the name of the compiler they use but I can't recall the name now)
• MingW
• GCC/G++
• Apple GCC
• Apple LLVM

But I suppose the real interest here is in figuring out which development platforms to support, by providing ready-made project files for the IDEs, makefiles, etc.

If that's the case, I suggest going for CMake, since it can generate Makefile-like files for pretty much any of the platforms mentioned here, and all the IDEs mentioned here can import a Makefile-like file to generate a project.

In any case, handing out ready-made project files for IDEs may not be a good idea because it's a lot of work (maintaining several platforms instead of just one) and you can never figure out the details of each person's configuration (include directives with the right directories, executable names, etc), so it's better to just let the IDE generate the project from a Makefile and be done with it.

[Daiky]

I use MS Visual Studio c++ 2010 express. I modified my OpenXcom.rc locally to make it work.

[Yankes]

I use NetBeans&MinGW and hand made configuration for openXcom.

[SupSuper]

Ok ok I've changed the title so people will quit bickering over the fact that I couldn't think of a better word than "compilers".

But I suppose the real interest here is in figuring out which development platforms to support, by providing ready-made project files for the IDEs, makefiles, etc.

If that's the case, I suggest going for CMake, since it can generate Makefile-like files for pretty much any of the platforms mentioned here, and all the IDEs mentioned here can import a Makefile-like file to generate a project.

In any case, handing out ready-made project files for IDEs may not be a good idea because it's a lot of work (maintaining several platforms instead of just one) and you can never figure out the details of each person's configuration (include directives with the right directories, executable names, etc), so it's better to just let the IDE generate the project from a Makefile and be done with it.

You've hit the nail on the head.

I personally don't like the typical OSS-mindset of "here's some software, it's your job to figure it out". It is always a pain the first time you run into a new project and have to track down dependencies, figure out the configuration, fix the obligatory errors and set everything up the one way the development team intended to work. I want to attract users, not push them away, so I do my best to make the code as simple to get up and running as possible, even if that means more work for me just for less work for the users.

But it's become a bit annoying lately with the growing amount of tools that require exact lists of files instead of just "src/*.*". People tell me "oh it's ugly to specify your source files like that", you know what's uglier? Having your file structure redundantly repeated over a whole bunch of extra files that we have to edit everytime we need to add/remove stuff because it's the "proper" way. It's a fact, the more steps you add to a software's maintenance, the less encouraged you are to maintain it. And we don't wanna be discouraged.

So now that we have things like CMake, my plan was to just drop the least-used projects and let people generate them themselves (plus there'll be a wiki where everyone can share their own howtos soon). The reason I don't completely drop everything but CMake is because:

1. It's an extra step whenever we just need to add/remove files. Close everything, edit the CMake, regenerate everything, restore all our little project tweaks and get everything back on track.
2. It's not something I'm too familiar with configuring myself, and I don't wanna have to rely on third-parties to keep my code up and running.
3. Invariably, some people just don't like CMake.

[Yankes]

I failed on compiling Yaml using CMake and switch to using Yaml  source code as part of openxcom
only drawback of this is when i do `clean` i need recompile Yaml too.

[gchevallereau]

CMake here(Makefile on Linux, both Makefile and Visual on Windows).

1. It's an extra step whenever we just need to add/remove files. Close everything, edit the CMake, regenerate everything, restore all our little project tweaks and get everything back on track.

You don't need to do that. You can perfectly edit the CMakeLists.txt from visual and just build your project normally. Visual Sutdio project will be rebuilt automatically. Tweaking the build is only needed, when you generate the project for the first time.

I want to attract users, not push them away, so I do my best to make the code as simple to get up and running as possible, even if that means more work for me just for less work for the users.

I guess that depend what you called users. I understand your point for developpers. But normal users won't compile openxcom, they just want precompiled binaries.

[borfast]

Ok ok I've changed the title so people will quit bickering over the fact that I couldn't think of a better word than "compilers".
You've hit the nail on the head.

Sorry, I didn't mean to be a PITA, I just wanted to make sure everyone understood what your intention was, so that you'd get meaningful responses.

So now that we have things like CMake, my plan was to just drop the least-used projects and let people generate them themselves (plus there'll be a wiki where everyone can share their own howtos soon). The reason I don't completely drop everything but CMake is because:

1. It's an extra step whenever we just need to add/remove files. Close everything, edit the CMake, regenerate everything, restore all our little project tweaks and get everything back on track.
2. It's not something I'm too familiar with configuring myself, and I don't wanna have to rely on third-parties to keep my code up and running.
3. Invariably, some people just don't like CMake.

1. Some IDEs support CMake, either out-of-the-box or by adding a plugin. Perhaps you can let your IDE take care of those changes for you.

2. It's not that hard, and if your IDE supports it, it's even easier. I'd be motivated to learn it if it meant reducing the amount of work I have to do for supporting the people who want to compile my code.

3. It's your project. F*** them Seriously, you will always find some resistance, whatver choice you make, and unless you want to support every major tool in existance - which you don't, that being the exact purpose of this poll - you will always have some people unhappy with something. But you can always accept contributions from them, in order to unofficially support their platform of choice. Just drop their build files somewhere in "build/<platform>/*.*" and that's it. Personally I don't like that, because it will eventually mean that those build files will be out of sync with the project, and someone will make a fuss about it. But apart from having a big team and people dedicated to maintaining those build feils, I think that's the only sane way of supporting a lot of platforms.

Raúl

[scarabeus]

The build system depends  on the needs and targets.

As I said even previously the autotools work on windows and mac (on win you just need mingw). But it is much more convenient to use the CMake.
On the other hand CMake syntax is way more uglier than the autotools (just check how those look like in the git) and currently it does not work/install all the files up to the linux standart (yes i could fix that, but autotools can do that out of the box right away).
The autotools also bring you powers of awesome packaging for release. Just try running "./autogen.sh && ./configure && make dist" and you will get proper tarballs that you can put on some webspace for release

So you can be sure that most people using this on linux will use autotools (in this area I count even distro packages), as an example see the buildscript for Gentoo/Sabayon/Funtoo distros. https://gpo.zugaina.org/AJAX/Ebuild/2429990/View