Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A Modern C/C++ build tools (Simple, Fast, Cross-platform)

xmake.io

Post reply on HN
Print view View original

51–57 of 57 posts

Re: Show HN: A Modern C/C++ build tools (Simple, Fast, Cross-platform)

#51

Post by lightgreen »

reubenmorais wrote: post #25
flohofwoe wrote: post #22

Earlier quoted context omitted.

I'm sure once it works, bazel is great and all, but Windows seems to have been an afterthought (which makes that whole "industry standard" thing a bit "complicated"). The hoops one has to jump through to get it running on Windows are a joke (TBH, the list of prerequisites and potential issues looks like a UNIX programmer was confronted for the first time with Windows): https://docs.bazel.build/versions/1.1.0/install-…

Bazel, like most Google open source projects, has a strong focus on Google's internal needs. Another similar Bazel surprise is how many hoops you have to jump through for the rare task of... debugging a cc_binary on macOS: https://github.com/bazelbuild/bazel/issues/2537

> Bazel, like most Google open source projects, has a strong focus on Google's internal needs

This is only partially true: internally they have Blaze, which is a different version of Bazel. I think Bazel is just not yet mature enough, and they released version 1.0 too early.

Re: Show HN: A Modern C/C++ build tools (Simple, Fast, Cross-platform)

#52

Post by lightgreen »

jstimpfle wrote: post #46
jstimpfle wrote: post #44

Earlier quoted context omitted.

> MSBuild OMG don't say the name, it causes me physical pain. That XML crap which can't decide whether to be a shitty static GUI-editable build format or a proper description language that you can actually use. It ended up being neither (to be fair the first can't really be achieved for non-trivial projects). It's one of the worst designs I've had to deal with. (I'm still in the process of cleaning up hundreds of .vc…

But, let's not forget to mention, MSBuild the "execution engine" is absolutely fantastic... Working in Visual Studio, it reliably detects the minimal amount of things to rebuild.

> it reliably detects the minimal amount of things to rebuild

So they managed to implement graph traversal which is a basic interview question everywhere? Every dummy build system do it, but for Microsoft that’s achievement!

Re: Show HN: A Modern C/C++ build tools (Simple, Fast, Cross-platform)

#53

Post by jstimpfle »

lightgreen wrote: post #52
jstimpfle wrote: post #46

Earlier quoted context omitted.

But, let's not forget to mention, MSBuild the "execution engine" is absolutely fantastic... Working in Visual Studio, it reliably detects the minimal amount of things to rebuild.

> it reliably detects the minimal amount of things to rebuild So they managed to implement graph traversal which is a basic interview question everywhere? Every dummy build system do it, but for Microsoft that’s achievement!

It's not about walking a dependency graph, but about getting the dependencies 100% right. In C, that's indeed very difficult, or at least a lot of work.

I don't know if you have tried MSBuild, but I've spent countless numbers cleaning up .vcxprojs, shifting things around, factoring into extern .props files, etc. Even on major changes I was often surprised how little rebuild was necessary. The granularity at which the system detects changes is not just per-file. It has per-file caches for the set of preprocessor variables, the set of include paths, all the little compilation and link settings, and so on.

So what it will do if you change the build file is, it will re-execute the build file processor and generate all the necessary build information for each C file. And then, it only rebuilds each file if a build dependency has actually changed in a relevant way for that file. For example, the order in which the preprocessor variables are defined does not matter (as long as they don't overwrite each other), but the ordering of include paths does. Also, if any of the files that were #include'd (transitively) in the last build changed since them, a rebuild is needed.

Compare that to the average crappy Makefile system that you are going to set up. The best thing you could achieve with Make will never be going to rebuild as little, or rebuild reliably the stale build products. I like Make for other reasons, but MSBuild is better and more robust.

Re: Show HN: A Modern C/C++ build tools (Simple, Fast, Cross-platform)

#54

Post by lightgreen »

jstimpfle wrote: post #53
lightgreen wrote: post #52

Earlier quoted context omitted.

> it reliably detects the minimal amount of things to rebuild So they managed to implement graph traversal which is a basic interview question everywhere? Every dummy build system do it, but for Microsoft that’s achievement!

It's not about walking a dependency graph, but about getting the dependencies 100% right. In C, that's indeed very difficult, or at least a lot of work. I don't know if you have tried MSBuild, but I've spent countless numbers cleaning up .vcxprojs, shifting things around, factoring into extern .props files, etc. Even on major changes I was often surprised how little rebuild was necessary. The granularity at which the…

I have spent large amount of time working with msbuild while migrating msbuild build into a different build system (including working on implementation of two way converter, from an to msbuild).

What you described (cache based on preprocessor flags) is really cool, in practice it does not give a huge win compared to proper modern build system like Bazel, and decent user interface (including the build language) and extensibility is much more important. Especially because it’s super hard to properly configure msbuild project with proper dependencies between modules.

I have a friend who worked at MS. He told stories how in their VS projects dependencies between modules (projects) were not configured, developers had to manually invoke compilation of dependencies. In theory it is possible to configure msbuild properly, in practice even MS employees failed to do so.

But I don’t consider msbuild a build system. For me it’s just a project format for VS which some developers commit to VCS. It’s great that MSBuild allows to have a proper C++ project definition with a custom command to actually build it (external build system), so VS sees proper project structure, but developers don’t have to deal with vcxproj files.

Re: Show HN: A Modern C/C++ build tools (Simple, Fast, Cross-platform)

#55

Post by jstimpfle »

lightgreen wrote: post #54
jstimpfle wrote: post #53

Earlier quoted context omitted.

It's not about walking a dependency graph, but about getting the dependencies 100% right. In C, that's indeed very difficult, or at least a lot of work. I don't know if you have tried MSBuild, but I've spent countless numbers cleaning up .vcxprojs, shifting things around, factoring into extern .props files, etc. Even on major changes I was often surprised how little rebuild was necessary. The granularity at which the…

I have spent large amount of time working with msbuild while migrating msbuild build into a different build system (including working on implementation of two way converter, from an to msbuild). What you described (cache based on preprocessor flags) is really cool, in practice it does not give a huge win compared to proper modern build system like Bazel, and decent user interface (including the build language) and ex…

> He told stories how in their VS projects dependencies between modules (projects) were not configured

Yes that's still an issue at my workplace as well. When I joined, there were no dependencies - all files were compiled redundantly for each project. So there were no issues with regards to reliably rebuilding dependencies, but of course it takes a lot longer to build. And there are serious maintainability issues with de-facto internal libraries, because adding or removing files to/from each "library" means that each dependent project file has to be updated. I've started to split out a few "library projects", and now we're starting to get the rebuilding issue. I think dependencies can be configured in *.sln files, but that probably means that they have to be configured separately for each project, i.e. it probably can't be done automatically when simply importing the library's .props file into a .vcxproj.

A nice middle ground could be to make .props files that just include .c files, meaning the library's files will be part of each project, so no rebuilding issues and no maintenance issues since the list of files that belongs to a library is maintained in one isolated place (the .props file). But that again means the files are built redundantly in each project.

But the long-term solution will be to maintain the build descriptions in better-suited in-house data structures (yeah like CMake, just not that scary) and to generate the MSBuild cruft from that.

Re: Show HN: A Modern C/C++ build tools (Simple, Fast, Cross-platform)

#56

Post by jacobush »

jhasse wrote: post #15
bsder wrote: post #8

Earlier quoted context omitted.

Scons is effectively dead, and I wish people would start removing it from the Python build systems web pages. Meson is written in Python and isn't dead. However, Meson requires a partner to actually build things--something like cmake or ninja. However, I think the original poster meant "Why Lua instead of Python?" And the only real answer is "Because that's what the author wanted to use."

btw: There's also Waf written in Python, which also isn't dead.

It’s pining for the fjords.

Re: Show HN: A Modern C/C++ build tools (Simple, Fast, Cross-platform)

#57

Post by reubenmorais »

lightgreen wrote: post #50
reubenmorais wrote: post #25

Earlier quoted context omitted.

Bazel, like most Google open source projects, has a strong focus on Google's internal needs. Another similar Bazel surprise is how many hoops you have to jump through for the rare task of... debugging a cc_binary on macOS: https://github.com/bazelbuild/bazel/issues/2537

I’d say it is Apple’s fault, not Google’s: Bazel correctly does not include absolute paths into binaries (Bazel focuses on build reproducibility which is very good for caching and debugging of builds), and Apple toolchain does not provide convenient way to work with such binaries.

As a user, I couldn't care less. My goal is to build my application in debug mode. If the build system's view of the world is incompatible with the actual world, is that a failure of the world or the build system? At the end of the day, I still need to get my debug build working...
Post reply on HN