> >>>> As for your concerns about CMake being available or not: it's > >>>> available from all Linux and BSD variants I know because more and more > >>>> projects are moving to CMake because more and more projects are > >>>> concerned about cross-platform, including MSVC. It's not something > >>>> esoteric. > >>> > >>> As far as I know, there are still a lot of project against the ideas > >>> of using CMake to replace the autotools. > >> > >> The main reason why we do not use cmake is that it makes things much > >> more complicated for the end-user, while adding additional maintenance > >> requirements that we should get for free from the build system. > >> > >> Here's what I mean. > >> > >> In the autotools world, there is a very defined and extremely enforced > >> concept that above all, our goal is to make it *TRIVIAL* for the end > >> user to compile your software. Now let's clarify this. The end user > >> is the guy who knows nothing about development, nor of your project, > >> nor of autotools, nor of anything else. But he needs your project for > >> some reason. We want that guy to be able to do this: > >> > >> cd /tmp; /path/configure && make > > > > What do you expect to be the breakdown of how you (as committers) will > > build/debug/test ironCrate? For example, are these the right categories and > > reasonable estimates? > > > > 75% - Build on Linux for Linux (Wine) [1] > > 22% - Cross-build on Linux for Windows > > 2.8% - Build on Windows for Windows (all MinGW flavors) > > 0.2% - Build on Windows for Windows (VC++) > > > > Now turn it around. What do you expect to be the build breakdown for devs > > trying to use ironCrate? > > > > I would expect the Wine case to be merged with cross for Windows, I > don't think ironcrate would make much sense as part of Wine. What would > likely happen however is to cross build for Windows and test it under Wine. > > Personally, I never do MinGW->MinGW straight compiles, there is always a > cross somewhere, normally from Cygwin or Linux in a VM. > > For ironcrate downstream users, I expect: > 30% - Cross from Linux or other systems > 65% or more - Straight mingw* builds > 5% or less - VC++ builds > > As it stands right now, I don't think there is much utility in users > using it in MSVC other than as a curiosity since ironcrate has not reach > a point where it can cover msvcr*. Figures will change as features are > added. > > I put a high estimate for straight mingw-mingw builds mainly because > there is a weird fixation among some Windows devs to make everything > static. Likewise, figures will change as ironcrate matures.
>From the discussion, I believe autotools is clearly a better fit for this team. You appear to have hard-won expertise and are productive with the tool. To ask you to bear the time cost of researching and becoming proficient with cmake (or waf, etc) likely doesn't get any of us ironcrate any faster. But who knows, none of you appear to be slow learners. However, if you choose to use autotools, to better support the build-for-windows-on-windows scenario I ask that you also maintain a mingw32-make compatible Makefile. IIRC, this was Ozkan's suggestion near the very beginning of the discussion. The autotools election day promise of "making it trivial for users to compile your software" is a worn out old tub-o-shit for build-for-windows-on-windows scenarios. We should all stop proliferating this mind virus. Autotools on windows is like stuffing an elephant into cycling trunks, feeding it slimfast for 2 weeks, and hoping it wins the next Tour de France. Autotools *is* amazingly powerful, battle tested and highly usable (did I really admit that!?) on *nix systems even if it's ugly as hell. Sort of like going back and reading your old perl from 6 years ago ;) But ramming it onto build-for-windows-on-windows users is just cruel, especially for new users who haven't had the pure ecstacy of figuring out how to quickly get a working autotools system up and running on windows. Don't believe me? Forget all you currently know and go back to when you were a noob trying to build a cool open source pkg you just heard about. How many downloads and how many steps were needed to get a working toolchain? Don't know? Here's a push in the right direction: https://github.com/oneclick/rubyinstaller/blob/master/config/devkit.rb#L30-L68 https://github.com/oneclick/rubyinstaller/blob/master/config/compilers/mingw64.rb#L3-L37 Then, what else do you need to do to get all those pieces to play nicely together? Clearly not all are needed, but you get the point. Waste of time, but we're all grateful to the mingw.org folks for their hard work to make the pill a little less bitter. This drama is completely unnecessary, and toxic on many levels for a project. All one should need to do is download Ruben or Nixman's build, clone ironcrate, *possibly* download 1 easy-to-install build tool (I just can't give up on cmake or waf!), tweak PATH, and off you go to nirvana. Jon ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net/ _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
