OpenXcom Forum
Contributions => Programming => Topic started by: SupSuper on November 09, 2011, 05:50:04 pm
-
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! :P
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.
-
Eclipse? I only know this as editor not compiler.
as for compiler I use MinGW for openXcom
-
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.
-
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).
-
Technically, the question us about IDEs, not compilers per se.
I use Xcode with Clang/LLVM as a compiler.
-
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
-
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.
-
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.
-
I use MS Visual Studio c++ 2010 express. I modified my OpenXcom.rc locally to make it work.
-
I use NetBeans&MinGW and hand made configuration for openXcom.
-
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". :P
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.
-
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.
-
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.
-
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". :P
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
-
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 (https://gpo.zugaina.org/AJAX/Ebuild/2429990/View)
-
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.
CMake and Visual Studio don't tend to play well together.
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.
Most Linux users prefer to compile it themselves, probably because precompiled binaries don't play well with all the different distros and setups out there.
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.
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.
AFAIK there are no such solutions for Visual Studio. And well I'm not completely clueless, if push comes to shove I will dig around the files to tweak and fix something, but more often than not the contributors handling the CMake/Autotools do a much better job than me.
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
Well I'm one of those people. ;) I'm primarily a Windows developer (a capital OSS offense!), so I could just maintain a VS project and f*** the rest, but that wouldn't be very nice. :P
And that's pretty much how it works right now. Most "secondary" build tools like CMake/Autotools scripts are maintained by outside contributors, and I'd love to just leave it all in their capable hands but eventually the code updates faster than the tools and if someone is using them I have to step in myself and keep everything in sync.
It probably doesn't help that I haven't been able to keep up with Linux support, since my distro is currently broken and I only have enough experience to put out a binary that apparently only works on my machine, so whenever there's an issue there I'm pretty much helpless. Maybe someone would be interested in keeping all these things in check for me and make proper binaries and packages and what not?
-
To tell you the truth, I don't like CMake either. I do find it easier to understand than the unholy mess that a Makefile is but it's far from perfect. To tell you the truth, the best (i.e. easier to understand and use) system I've seen so far is Scons (https://www.scons.org/). Last time I used it (a few years ago) it wasn't supported by many (if any) IDEs but that seems to be changing: https://www.scons.org/wiki/IDEIntegration
If you don't know it, check it out, you may find it interesting. :)
But that's where the problem starts and that's what I was talking about before: everyone has his/her favourite build tool but you need to select just one that everyone can use - even if they don't like it. I don't like autotools/autoconf but I've been using it for years. I don't like cmake either but I've used it quite a lot as well. But in both cases, I've used them more as an end-user than as a developer, and I think this is the important point: end-users will be able to compile the code without needing to fiddle with the build scripts, so the chosen build tools should be the ones that you, the developer, are more comfortable with, because even if the end-user doesn't like that specific tool for development, he/she won't have to deal with it and will only need to execute a few of commands to run it.
-
On the other hand CMake syntax is way more uglier than the autotools
Funny, i have the exact opposite opinion. I think it's a matter of taste ;)
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).
I'm sure that the build work(maybe not on MacOS). About installation, i can't see any missing file. Do you have a specific example ?
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
mkdir build ; cd build ; cmake .. && make && cpack -G DEB && cpack -G RPMAutomatic package generation for Windows/Linux(and MacOS, once i have acces to a mac).
CMake and Visual Studio don't tend to play well together.
Strange, I have seen it work at my previous job. Might be a version problem(VS 2010 against VS 2008).
Most Linux users prefer to compile it themselves, probably because precompiled binaries don't play well with all the different distros and setups out there.
Apart from Gentoo/LFS user, i'm sure that what Linux(and BSD people) wants is an OpenXcom package available in their repositery. So they can use the power of their package managers to install it.
By the way, the linux auto builder generate ZIP and Debian package each time a build is successful. Might be interesting to make them available. It also build the documentation.
AFAIK there are no such solutions for Visual Studio. And well I'm not completely clueless, if push comes to shove I will dig around the files to tweak and fix something, but more often than not the contributors handling the CMake/Autotools do a much better job than me.
The benefits of experience ;)
Last time I used it (a few years ago) it wasn't supported by many (if any) IDEs but that seems to be changing: https://www.scons.org/wiki/IDEIntegration
If you don't know it, check it out, you may find it interesting.
I didn't know that scons now support IDE. interresting
so the chosen build tools should be the ones that you, the developer, are more comfortable with, because even if the end-user doesn't like that specific tool for development, he/she won't have to deal with it and will only need to execute a few of commands to run it.
Agreed, if someone want to use source package, there is not so much difference between
./configure && make && make installand
cmake . && make && make install
-
The thing I hated about scons was that it is a python script. As a win32 user this was a huge PITA in order to get it working and not something I wanted as part of my development environment. CMake was much better in this reguard (fairly lightweight).
The thing I *hate* about cmake is the developers' unwillingness to code in support to generate a build (makefile/visual studio/xcode) that wont try to regenerate itself (run cmake during the build process). I also dont like that when I change the cmake file and build (from VS) it has to reload itself about three times before it settles down. Maybe the newer revisions of cmake has fixed this. I never got the feeling from the mailing list that kitware had any interest in decoupling their generated solutions from their tool.
Despite all those issues I have with cmake, I still would use it over rolling my own build solution any day. It is excellent at making a makefile that does 90% of what I need, and its fairly trivial to add the missing flags for a specific platform.
Premake (https://industriousone.com/premake) is what I want to look into whenever I have time to see if I can replace cmake. I like that it uses lua for its input scripts, and I like that it just generates a project that contains no dependencies.
-
I like how we went from disagreeing on supporting everyone to disagreeing on supporting nobody. (exaggerating of course :P)
The thing I *hate* about cmake is the developers' unwillingness to code in support to generate a build (makefile/visual studio/xcode) that wont try to regenerate itself (run cmake during the build process). I also dont like that when I change the cmake file and build (from VS) it has to reload itself about three times before it settles down. Maybe the newer revisions of cmake has fixed this. I never got the feeling from the mailing list that kitware had any interest in decoupling their generated solutions from their tool.
It still does this (this is what I meant with VS and CMake not playing well). VS doesn't handle massive reloads well, and CMake regenerates the project during compiling even though VS can't reload the project during compiling, so VS tends to just give up and crash.
Also personally I don't like how the generated projects come out, CMake adds a whole bunch of extra options and stuff which I have no clue what it does or doesn't even make sense, in the end there's so much going through CMake I'm not sure what the project does anymore.
-
The thing I *hate* about cmake is the developers' unwillingness to code in support to generate a build (makefile/visual studio/xcode) that wont try to regenerate itself (run cmake during the build process).
Well, I disagree. Not doing this might end up with a broken build(for example, missing object file at link time).
It still does this (this is what I meant with VS and CMake not playing well). VS doesn't handle massive reloads well, and CMake regenerates the project during compiling even though VS can't reload the project during compiling, so VS tends to just give up and crash.
Question: which version of VS are you using ? Express ? Pro ? Because, i guess that the explanation. CMake use visual studio macro to handle the project reloading in VS. But those macro only work in pro version.
Also personally I don't like how the generated projects come out, CMake adds a whole bunch of extra options and stuff which I have no clue what it does or doesn't even make sense, in the end there's so much going through CMake I'm not sure what the project does anymore.
I'm not sure what you are talking about. CMake options or visual studio projects(zero_check, ...) ? If needed i can put an explanation somewhere.
-
Eclipse representin' 8)
On a related note, I noticed that the wiki is looking for details on compiling in various platforms and that Eclipse hasn't been done yet. Anyone planning on doing this? I've now worked with this program in both Linux (Gentoo & Ubuntu) and Windows w/ MinGW, and as it's been a while since I've trolled the OpenXcom code/project I wouldn't mind getting a bit more involved again.
On an also related note: SupSuper. A while back I noted that I was using Eclipse and included my .cproject and .project files in a Git push. I've since discovered that's a bad idea (I've been working on one of my own projects - sorry for the haitus :-/). Apparently they note system-specific information (ie: mingw32-make for Windows (instead of make for Linux) as well as library specific positions. I don't know if anything came of it after we spoke last time, but I wanted to pass that along.