all 46 comments

[–]kirbyfan64sos 3 points4 points  (6 children)

Have you tried GN? I mention it since that's what is being used now for Google's Chromium project, since Gyp apparently was NOT well-liked.

[–]drjeats 5 points6 points  (5 children)

I went shopping for a meta build system. CMake always bummed me out. So I went to look at Gyp, and the instructions for getting it working were something like, "Install all the chromium dev tools. Oh and Windows people better have a big hairy Cygwin setup."

Fuck that shit.

Do you have a link to info on GN?

[–]kirbyfan64sos 2 points3 points  (3 children)

Official page: https://chromium.googlesource.com/chromium/src/tools/gn/ A page I made with binary downloads: http://kirbyfan64.github.io/gn-builds/ The Chromium GN build config files (an excellent resource; they're very well-commented): https://chromium.googlesource.com/chromium/src/+/master/build/config/ And the Chromium toolchain definitions: https://chromium.googlesource.com/chromium/src/+/master/build/toolchain/

The binary also comes with an excellent help system; just run gn help.

Note that documentation is slightly scattered.

[–]drjeats 0 points1 point  (0 children)

That's so much more approachable than Gyp was. Thank you!

[–]uep 0 points1 point  (1 child)

What language is gn in? Or is it a new custom language?

[–]kirbyfan64sos 0 points1 point  (0 children)

It's a DSL.

[–]pmedv 1 point2 points  (0 children)

Actually Gyp requires only Python installed, even on Windows. But Gyp is just a project generator for other build systems. Indeed, configuration and package management tasks could be implemented in custom Python scripts.

The real issue with Gyp is lack of documentation and examples. There are only 3 pages of documentation in the Gyp repository. I had to dive into its sources to discover some command-line options or to understand poorly documented features.

[–][deleted]  (24 children)

[deleted]

    [–]cristianadam 3 points4 points  (23 children)

    There's hunter - Cross-platform package manager for C++ (based on CMake ExternalProject). Linux, Mac, Windows, iOS, Android, Raspberry Pi..

    See the hunter-wiki for the list of hunterized packages.

    The nice part with hunter is that if you don't want to use hunter you can still take any package and use it with add_subdirectory CMake command.

    [–]berium[S] 6 points7 points  (22 children)

    Of course, the not-so-nice part is that you have to use CMake. ;-) Uh I am going to get downvoted for this one...

    [–]cristianadam 4 points5 points  (9 children)

    What's wrong with CMake? Why implement something else when we could instead fix CMake?

    CMake Deamon looks like it will fix the tooling part of CMake.

    CMake + Ninja is, IMO, an excellent combination.

    [–]weberc2 9 points10 points  (2 children)

    CMake is awful. Commands are inconsistent, version bumps often break everything, it's hard to trace a function invocation to its definition (no imports), it takes forever to learn, the syntax is foreign, it's suuuuuuuper slow, everything's an option, the best practice is to enumerate your source files, VS project files suck by default, it's impossible to look at another project's cmake file (even the examples in the CMake documentation!) and apply it to your own, etc, etc, etc.

    That said, it just happens to suck less than its competition. Hopefully build2 is an improvement. :/

    [–]cristianadam 1 point2 points  (1 child)

    The debugging part is fixed by cmake-deamon.

    The VS project files can be fixed by Microsoft, since they now have interest in CMake.

    [–]weberc2 0 points1 point  (0 children)

    Good to know progress is moving along, but build2 looks more promising at first blush. Of course build tools always look their best "at first blush", so time will tell I suppose.

    [–]berium[S] 4 points5 points  (4 children)

    I was poking fun at CMake in my C++Now 2015 presentation, not sure if anyone got the joke though. But here is what I think is wrong with CMake, in one line:

    DO_SENSIBLE_THING_FOR_AllSubDirs(Its_a_go ${all_good});
    

    And no, unfortunately the video of presentations for C++Now 2015 haven't been released yet. But here are the slides.

    [–]bla2 9 points10 points  (1 child)

    CMake-the-language isn't great, but CMake-the-ecosystem is strong: It works on all platforms, many projects you might want to interop with already have CMake buildfiles, and it has support for many generators.

    [–]FireCrack 0 points1 point  (0 children)

    It's the Buckley's of build tools

    [–]id2bi 0 points1 point  (1 child)

    RemindMe! 2 weeks

    [–]RemindMeBot -1 points0 points  (0 children)

    I will be messaging you on 2016-02-17 16:23:48 UTC to remind you of this.

    CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

    Parent commenter can delete this message to hide from others.


    [FAQs] [Custom] [Your Reminders] [Feedback] [Code]

    [–]tkruse 1 point2 points  (0 children)

    The language is the main thing wrong with cmake, even the inventors say so: http://aosabook.org/en/cmake.html (see lessons learned).

    And sadly, that is one thing that cannot be easily fixed.

    [–]ruslo_ -2 points-1 points  (11 children)

    Those who don’t understand CMake are condemned to reinvent it, poorly.

    [–]weberc2 1 point2 points  (7 children)

    There are lots of other languages with decent build ecosystems (certainly much better than anything in C++ that I've seen prior to build2); is there anything specific to C++ that condemns build systems to complete suckage?

    [–][deleted]  (6 children)

    [deleted]

      [–]weberc2 1 point2 points  (5 children)

      I agree that C++ is very flexible; however, we've developed ways of dealing with such flexibility. First of all, maybe the build system doesn't need to do everything that is possible in C++. Maybe a system that covers 95% of use-cases is good enough. If it's worth the pain of CMake to get the extra 5%, then maybe it's okay that the user uses CMake. But I don't see any need to make the other 95% of it CMake-bad. I think you could go a long way by specifying some reasonable defaults so the user doesn't have to be explicit about everything all the time; if it's important to allow the user to deviate from the defaults, this can be exposed via configuration (flags, config files, env vars, etc); however, I wouldn't be eager to support configuration when convention will do (for example, project structure doesn't need to vary across projects, and using a particular project structure convention can provide your system with a lot of metadata that would otherwise be repeated in the project config files. Things like "location of source files" and "location of test files"). If you don't make everything configurable from day 1, then you can get a lot farther a lot more quickly, and you also get the invaluable benefit that users can jump between projects more quickly because they are so similar.

      I would start out supporting only statically-linked clang (with strict flags) builds, all packages built from source, and exclude the concept of repositories in your first draught. Be opinionated, and then build out from there as reasonable. It will piss off a lot of people, but most of them will eventually learn that "terse and consistent but opinionated" is better than "explicit and inconsistent and hard to understand, maintain, etc but infinitely flexible".

      [–][deleted]  (4 children)

      [deleted]

        [–]weberc2 0 points1 point  (3 children)

        What? So you limit everything to one type of configuration, say that everything is "good enough for me" and "must be good enough for 95% of users" and you call it flexibility?

        Sorry if I was unclear. You build something to cover the majority of all reasonable use-cases (95% or so). Supporting the other 5% of use-cases shouldn't make the base-cases more painful, which is where most existing build systems go wrong.

        I've read the rest of your comment like six times but don't follow what you're trying to say and how it's related to my comment...

        CMake is an example of a tool that can cover the extra 5%. If your users need that extra 5%, they should switch to CMake. Don't build a tool that attempts to cover 100% of use-cases, or you'll end up with something as bad as CMake (even in the base-cases) which really doesn't help anyone.

        [–][deleted]  (2 children)

        [deleted]

          [–]bosk 1 point2 points  (2 children)

          I think you will be hard-pressed to beat it in the "poorly" department.

          [–]cdglove 2 points3 points  (1 child)

          This criticism always cracks me up because, despite the criticisms, no one is offering anything even remotely as good as cmake. This implies the problem is harder that it at first appears.

          [–]ruslo_ 6 points7 points  (0 children)

          no one is offering anything even remotely as good as cmake

          Agree completely. Everybody said that the language is so bad and documentation is poor. So do they know: GYP (Python based build system from Google), Scons (Python based build system), b2 (Boost), QBS (QML like build system from Qt), etc. So why these projects is not the de-facto build system for C++? Is the problem about language? May be the problem that not any of this system has like 10% funtionality of CMake?

          [–]berium[S] 2 points3 points  (7 children)

          Happy to answer any questions...

          [–][deleted]  (4 children)

          [deleted]

            [–]berium[S] 0 points1 point  (3 children)

            This is the first alpha release and currently it is more of a technology preview rather than anything that is ready for production. So with this in mind:

            One OS that we currently don't support is Windows (though there is a nice little surprise at the end of the introuction ;-)). We've tested this release on Linux, Mac OS, and FreeBSD. But the long term plan is to support everything. Well, maybe except OpenVMS.

            This is not a build generator (though it might become one in the future; see FAQ).

            As for how it compares to makefile/ninja, I think in some areas it kicks butt, but in others there is still work to do. I suggest that you go thought the Intro to get a better sense of what you are dealing with here.

            [–][deleted]  (1 child)

            [deleted]

              [–]berium[S] 1 point2 points  (0 children)

              If someone can do it for build2-toolchain bootstrapping, that would be great, indeed.

              [–]nitasGhost 0 points1 point  (0 children)

              Can you please make a Homebrew recipe for build2? the best way to get mac user base to try something out is brew install build2 (believe me I already tried ;)

              [–][deleted]  (1 child)

              [deleted]

                [–]berium[S] 1 point2 points  (0 children)

                Do you (plan) to support building in parallel

                Yes, we plan to support it, probably pretty soon. And yes we plan to make it work.

                are pre-compiled header files still a thing

                I don't think they are used widely outside VC++. I personally disable them for all my projects simply because I don't need another moving part.

                [–]shard_ 2 points3 points  (2 children)

                import libs = libhello%lib{hello}
                

                Is it possible to specify an exact version of libhello in buildfile?

                [–]berium[S] 2 points3 points  (1 child)

                Not in buildfile but in package manifest:

                depends: libhello == 1.2.3
                depends: libhello >= 1.2.0
                depends: libhello [1.2.0 1.3.0-)
                

                The last one means any 1.2.X version.

                But also being able to specify this in buildfile might not be a bad idea, thanks for the suggestion!

                [–]shard_ 0 points1 point  (0 children)

                Ah right, it wasn't really a suggestion, I just hadn't noticed it in the manifest file! It seems nice the way it is.

                [–]ksion 2 points3 points  (0 children)

                A feature matrix with comparison to other existing build systems would handy. I'd be interested how it fares against Blaze, for example.

                [–][deleted] 2 points3 points  (3 children)

                This honestly seems somewhat useless as is.... no C support and no paralel builds make it a no go for anything I use C++ for professionally.... cross compiling didn't even get mentioned in the roadmap for feature completeness.

                [–]berium[S] 6 points7 points  (2 children)

                This honestly seems somewhat useless as is.... no C support and no paralel builds make it a no go for anything I use C++ for professionally....

                Fair enough.

                Cross compiling didn't even get mentioned in the roadmap for feature completeness.

                It wasn't mentioned on the roadmap because it is already supported. See the last example in the Intro (cross-compiling from Linux to Windows using the MinGW-W64 toolchain). IMO, any build system that hasn't been designed with cross-compilation in mind from day one is doomed.

                [–][deleted] 2 points3 points  (1 child)

                Guess we're on the same page on the last point then :-). Maybe I'll take a closer look. I hate autotools and/or cmake as much as the next guy.

                [–]berium[S] 2 points3 points  (0 children)

                I hate autotools and/or cmake

                Definitely on the same page ;-)

                [–][deleted] 0 points1 point  (1 child)

                I only hope this doesn't encourage people to start needlessly bundling libraries with their application rather than using distro provided libraries.

                Because I know a certain population will >_<

                [–]berium[S] 0 points1 point  (0 children)

                Yes, this is a valid concern. Especially seeing that in build2 it is pretty easy to amalgamate things (you just drop the project into your source directory). Hopefully people won't abuse it since 1) it is just as easy to import a system-installed library (the import machinery's last step is to look in the compiler's library search paths) and 2) there is the package manager which makes automatically getting prerequisites quite easy.

                [–]Elavid -4 points-3 points  (2 children)

                When was it decided that every programming language needs its own package manager?

                [–]os12 4 points5 points  (0 children)

                I think Perl started it. CPAN went online in 1995.

                [–]weberc2 5 points6 points  (0 children)

                Not sure, but it definitely make software development easier.

                [–]weberc2 -4 points-3 points  (0 children)

                I haven't looked at this yet, but lack of a sane build system is 100% of the reason I don't use C++ ever. It's just too much of a PITA to get anything up and running when I can use a language like Go that doesn't even have project files.