![[de]](/mwf/flags/de.png "Germany")
If that's the official reason, I want the Visual C++ project files back so I can also skip a step in my tutorial.
The reason is that Günthers IDE isn't supported by cmake and needs automake files to work. Or something.
Fortunately, it should be much easier to share the list of files between automake and cmake than between lots of IDE specific project files. Also, the CMakeLists.txt is still not a full replacement for every option configure.ac/Makefile.am have.
It's also no full replacement for all options Visual C++ project files have... or maybe had. Isn't the whole point to sacrifice some build-environment-dependent flexibility for portability?
No, the point is not having to edit those huge msvc-project files when something changed and not being able to test the result. One can test both cmake and automake on every platform we support (though they are probably both broken on macosx due to lack of testers), so that's no reason to drop either one. But well, we could put the msvc project files back until someone complains about them being outdated or someone forgets to update the CMakeLists.txt, but updates the msvc project files. And the same goes for automake: As soon as they do harm, I'm ok with removing them - but I'll keep using them myself.
Well, last time I checked you could theoretically start Visual C++ Express with wine, too - so the platform thing is not really a strong argument. But I was careful to talk about build environments - I don't want to install Cygwin or MinGW just for checking Autoconf. If I wanted a Unix environment, I'd start Linux.
And apropos harm: There are about 5 files plus one directory in the root alone just to make Autoconf work...
And apropos harm: There are about 5 files plus one directory in the root alone just to make Autoconf work...
> I don't want to install Cygwin or MinGW just for checking Autoconf. If I wanted a Unix environment, I'd start Linux.
I'm only checking the CMake build. If some change breaks autotools - too bad. IMO, one build system should be enough, but I don't care about removing autotools since they don't get in my way. I believe we're only keeping the autotools files around so Anjuta works, and cmake is the preferred solution to build on Linux as well, but I might be mistaken.
> And apropos harm: There are about 5 files plus one directory in the root alone just to make Autoconf work...
If it bothers you, we could remove config.h.in (a generated file) and autogen.sh (which only exists to shorten the readme a bit), leaving autotools/, configure.ac and Makefile.am.
And okay, I could test msvc files. But that doesn't make extracting changes to them and porting them to CMake and/or Automake any easier. I probably should also confess that the real cause was the addition of the code::blocks project file, and my fear that the amount of project files would get out of hand. So the goal was to replace three project files with one CMake file (I still hope that somebody does the xcode part), and prevent the addition of yet more ones.
> And okay, I could test msvc files. But that doesn't make extracting changes to them and porting them to CMake and/or Automake any easier.
You don't have to explain your reasoning, I agree completely. I just don't see why we don't go all the way then. And yes, I will look into XCode once my diploma thesis deadline has passed.
You're lucky, you can make a diploma. I only can become a Master.
> I just don't see why we don't go all the way then.
Because deleting the automake files does not provide as much upsides as deleting the msvc project files did: Reading Makefile.am diffs is trivial (I don't intend to make anyone read Makefile.am diffs, but we might get patches from somebody who only updates that file), and we can just tell people to use CMake should the Makefile.am get outdated. I also don't like CMake that much, and don't want to lose the work I put into making the autotools build files portable.
> But well, we could put the msvc project files back until someone complains about them being outdated or someone forgets to update the CMakeLists.txt, but updates the msvc project files.
I'd rather not. MSVC project files have the tendency to create huge diffs when someone uses a different version of VC than the previous guy. That's actually the main objection I have to checking in generated files.
Also, reading the diff to see that someone changed some setting from 2 to 3 doesn't actually tell me what that does, and neither does the documentation. When I see the patch adds /MT to the CMake file, I can at least look up what that switch does.
If you can autogenerate the project files from CMake on a linux or macosx system, we could put those into the repository. I just don't want to deal with frustrated windows users who can't compile the source because the project files were left behind.
![[fi]](/mwf/flags/fi.png "Finland")
That´s why I hate compile anything on my winXP: project files are always at least 3 years old even if the source is still under development. OC now very easy compile
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
