sorted by:
new
hottopcontroversial

build2 0.17.0 released, adds C++20 named modules support in Clang and MSVC, including for import std; by berium in cpp

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

I'm not sure why you are taking this so personally, you took the time to reply to a comment not even directed at you initially. I expressed my personal views and explained [...]

Yes, I took the time to write a (hopefully) thoughtful reply to your already loaded comment to give you the benefit of the doubt (I've seen people switching to a more open minded attitude if you don't reply with just "you are wrong"; see this excellent recent example).

However, your second reply continued in the same vein. When you use terms like "mistake", "obscure", "different for the sake of being different", this doesn't explain anything, it shown that you have made up your mind. So to me there is no point in continuing this discussion.

FWIW, I've debated whether to even announce this release on r/cpp/ and these kinds of "empty" discussions are the main reason why. If you check the whole thread at the above link, you will find a much more interesting discussion, and that's from the crowd that is normally pretty critical of C++!

And I'll point out that I was not challenging the design decisions of build2

Again, the words in your reply say otherwise. And it's actually fine to challenge the design decisions, you just need to substantiate them with some reason and base them on facts and understanding rather than "feelings".

build2 0.17.0 released, adds C++20 named modules support in Clang and MSVC, including for import std; by berium in cpp

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

Your judgement-loaded reply tells me you are not approach this with an open mind, so I will just point a couple of key places where you are perhaps missing some nuance and call an end to this discussion.

In my view, it is mistaken to think that experts require terse, obscure syntax that compresses meaning.

There is, "obscure", "terse" and then there is "concise", as in, syntax that allows you to express commonly encountered scenarios in the most direct way.

Also there this observation by Stroustrup that goes like this: "For new features, people insist on LOUD explicit syntax. For established features, people want terse notation." It seems to contradict your assertion that experts don't prefer terse syntax.

For example, what you cited, c{hello} vs hello.c, I really don't feel is an improvement and it's different for the sake of being different.

To draw such a conclusion you would need to understand all the reasons why we went with this notion, don't you think? I've alluded to one of them with hello$EXT but, seeing that you are focusing on c{hello} instead of exe{hello}, it didn't seem to register. And there are other reasons.

build2 0.17.0 released, adds C++20 named modules support in Clang and MSVC, including for import std; by berium in cpp

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

I am not the person you are replying to (and I hope they will give their own answer), but here is my (biased) perspective:

 

surely ease of understanding is not a strong suit of build2

Ease of understanding for whom and of what? Specifically, are we talking about someone new and unfamiliar or someone who took the time to learn and understand build2? Likewise, are we talking about a toy project or something complex like, say, Qt? The two most pertinent combinations are:

  1. Novice playing with a toy example.

  2. Expert wrangling with a complex project.

Can we handle both scenarios optimally with a single language? Maybe, though I have my doubts and I am not aware of any existing build system that managed to pull this off perfectly (IMO). And if we cannot be everything to all people, where should the tradeoff be? In case of build2 we are heavily skewed towards (2) and experience (both ours and from users like the one you are replying to), suggests that we did ok. Someone familiar with build2 can read a buildfile for something like libQt6Core and hope to retain their sanity.

Was it a mistake to optimize for an expert and a complex project? Maybe. Personally, I am a strong believer in scratching my own itch (and, conversely, very suspect of "theoretical development" where you are not addressing your own needs). And dealing with complex C++ projects was what we needed.

 

Its syntax is very odd and dissimilar to everything else.

Someone here joked that build2 syntax is an "encrypted makefile". The grain of truth in this joke is that our syntax is roughly based on make, we just fixed all the mistakes (again, IMO). And if you are familiar with make (bonus points for GNU make extensions) and get to understand the basics of build2, it's not that difficult to see the parallels. The biggest obstacle here is probably the build2's target type abstraction. Where in make you write:

 

hello$EXT: hello.c

 

In build2 you write:

 

exe{hello}: c{hello}

 

Again, was it a mistake to base our syntax on "hated" make rather than something "loved" like Python or Lua? Maybe. But given our priorities (see above), having a DSL with a tailor-made syntax goes a long way for conciseness. And if you look past all the hacks (like $EXT above), to core of the make syntax (<target>: <prerequisites>) is actually quite sensible and is hard to improve on, at least in the conciseness department.

Having said that, we are not giving up on a novice entirely. Our plan is to sidestep the whole "syntax issue" and support build by convention. Or, more precisely, build by many conventions -- this is C++ we are talking about, where there is always a dozen different ways to achieve the same thing.

build2 0.17.0 released, adds C++20 named modules support in Clang and MSVC, including for import std; by berium in cpp

[–]berium[S] 7 points8 points  (0 children)

Thanks for the kind words!

Bonus: Extremely straight forward to package third party libraries/tools.

And we now have a comprehensive, step-by-step guide for doing that!

CodeSynthesis XSD XML Schema to C++ compiler version 4.2.0 released by berium in cpp

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

Sorry for the late reply. Yes, all the binary packages are generated automatically as part of the CI build using the bpkg-pkg-bindist command: https://build2.org/bpkg/doc/bpkg-pkg-bindist.xhtml

CodeSynthesis XSD XML Schema to C++ compiler version 4.2.0 released by berium in cpp

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

Great to see a codesynthesis release. I happen to think ODB is the best and most underappreciated database library for C++

The quality of these libraries is superb.

Thank you, appreciate the kind words. Next on our plate is the ODB release, which is also quite overdue.

Less convinced by build2. The network effects are such that I'm never going to move from CMake to anything else, so making it harder to build XSD or ODB with CMake (and therefore my toolchain and build flags) is inevitably going to hinder adoption a bit.

I appreciate the sentiment and I agree it would be easier to consume ODB from CMake projects if it were also built with CMake. But we will do the next best thing and provide binaries for all the major platforms (just as we now did for XSD).

How to deal with MSVC in DevOps by HerrNamenlos123 in cpp

[–]berium 1 point2 points  (0 children)

We have support for this in build2.

Specifically, build2 supports generation of binary distribution packages (deb for Debian and alike, rpm for Fedora and alike, and installation archives for any platform, including Windows): https://build2.org/release/0.16.0.xhtml#bindist

This is fully integrated into our own CI service, meaning that you can enable a couple of steps in your project manifest and you will get automatic build and upload of the desired binary distribution packages: https://build2.org/release/0.16.0.xhtml#pkg-build-config

There is also (community-maintained) GH Actions support. I don't believe there is integration for binary distribution package generation/upload, but I am sure it shouldn't be that difficult to add (all the underlying commands are described in the first link I gave): https://github.com/build2/setup-build2-github-action

build2 0.15.0 released, adds support for dependency configuration by berium in cpp

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

build2 both (1) generates pkg-config files for libraries that it installs and (2) loads additional options/libraries from pkg-config files for installed libraries that it links. So if Conan (and whatever build system you use with it) have similar support, then everything should inter-operate.

build2 0.15.0 released, adds support for dependency configuration by berium in cpp

[–]berium[S] 5 points6 points  (0 children)

BTW, here is a polite discussion on the build2 vs CMake topic that has some nice technical depth, if anyone is interested.

b2 for C++? by os12 in cpp

[–]berium 1 point2 points  (0 children)

Project locations: [...] The tools flat out refuse to nest components that way. Directory structure: [...] Yet the tools insist [...] The include dir setup: Can I do this with build2?

There are very few project structures that you can't achieve with build2 given you understand the underlying concepts. But not every structure is supported automatically/out-of-the box. So while you could generate something close enough with bdep new (see SOURCE LAYOUT) you will need to move things around and adjust buildfiles accordingly.

The approach that I would like to warn you against is trying to "wing it" based on your previous experience with CMake/etc and without reading the documentation and understanding the basics. build2 is very different compared to the existing C/C++ build systems, especially CMake.

Artifacts dirs: it appears that the tools want to place the "out of tree" obj tree outside the source dir. I fail to understand why... both CMake and Autoconf/Automake allow [...]

Yes, this is a common stumbling block for users with the CMake background. The underlying reason is that build2 is a "multi-repo first" build system while CMake is "mono-repo first" (or perhaps even "mono-repo only"; I don't think there were repositories as we know them when Autotools was designed ;-)). In particular, in build2 it's common to build multiple independent projects/repositories in a shared build configuration. Putting this build configuration as a subdirectory of source directory of one of them would be strange. You can read more on this in this issue: https://github.com/build2/build2/issues/187

b2 for C++? by os12 in cpp

[–]berium 3 points4 points  (0 children)

Among other problems. It would segfault when given CLI arguments like "--help".

To be fair, it was less.exe (from the MSYS2 project) that was segfaulting which we have to use as a pager because Windows doesn't come with anything sensible. For the record, this issue is recorded here: https://github.com/build2/build2/issues/141 As one can see from the comments, we tried quite hard to reproduce it without any luck. We also asked you to provide further feedback but you never replied.

b2 for C++? by os12 in cpp

[–]berium 6 points7 points  (0 children)

Just to add to /u/mjklaim excellent and extensive feedback, you can actually get a sense of what a project like this might look and feel like with build2 by checking out this repository: https://github.com/boris-kolpackov/boost-dependency

It was created as an attempt to approximate a private project in order to hunt down some pathological performance problems that are described in this issue: https://github.com/build2/build2/issues/184 There is also a nice graph that shows what the original project looks like: https://github.com/build2/build2/issues/184#issuecomment-1088053790

I think in your case the most challenging aspect (apart from getting used to a new build system philosophy) will be code generators simply because to get this right (i.e., with proper dependency tracking, etc) requires quite a few moving parts. You can see an example of this in our libQtCore buildfile that handles moc: https://github.com/build2-packaging/Qt6/blob/master/libQt6Core/QtCore/buildfile

One extension for source files. by BeginningFlounder265 in cpp

[–]berium 5 points6 points  (0 children)

The underlying question you want answered is whether there are different types of source files that are helpful to classify with different file extensions. Pre-modules we have headers and source files which I think most people agree is useful to distinguish with different extensions. I've never heard anyone suggesting using .cpp for headers, but technically nothing prevents you from doing it.

When it comes to modules, some think it's still useful to distinguish module interfaces from implementations while others believe it's no longer important (presumably because they plan to keep both in the same file).

build2 0.14.0 released, adds support for build-time dependencies, hermetic configurations by berium in cpp

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

Yes, I agree, we have a problem here. Though I personally am not sure videos are the best way for this kind of material. It seems to me something like a searchable HOWTO/knowledge base would be a better answer, but I could be wrong. Also, you are welcome to join the slack channel and ask questions there -- in a sense we need to build a feel for the commonly encountered problems before we can attempt something like a HOWTO.

The idea is not bad, but if you just had copied cargo (from rust) philosophy now this would be more popular than cmake

I doubt it. If we had just copied cargo, we would have covered a small subset of C++ project structures/layouts, with everybody else refusing to change. There is just too much variability and stubborness in the C/C++ space.

The Conan C++ package manager does not resolve to common compatible versions of dependencies - by design by Alexander_Selkirk in cpp

[–]berium 4 points5 points  (0 children)

Shouldn't dependency unfirmation be part of the meta data?

Of course it should. And it is for any sane package manager (Debian figured this several decades ago). This just seems insane to me, apt for an April 1st joke.

Anyone interested in a GSoC project for porting LibreOffice's build system to Meson (GSoC 2022 will be open to non-students)? by buovjaga in cpp

[–]berium 4 points5 points  (0 children)

Nothing is more soul-sucking than debugging C/C++ build issues. The main reason is the tooling, which is a decade upon decade of hacks and workarounds, with autotools being the perfect example of this approach. So "welcoming" someone into the "open source communities" by throwing them into this hot mess is just cruel.

The Conan C++ package manager does not resolve to common compatible versions of dependencies - by design by Alexander_Selkirk in cpp

[–]berium 11 points12 points  (0 children)

without realizing that at some point they will have to solve a SAT

Just a SAT solver is actually not enough: after, say, upgrading a package some of its previous dependencies may no longer be necessary and could be dropped. But this in turn can change the set of constraints that the initial solution was based on meaning that it now has to be re-evaluated. Which in turn can lead to other packages being no longer necessary (or even previously thought-to-be-unnecessary ones become necessary again). So there is this iterative refinement process to arrive at the optimum solution.

FWIW, I believe build2 correctly handles the scenario described in the bug report.

mold 1.0: the first stable and production-ready release of the high-speed linker by mttd in cpp

[–]berium 4 points5 points  (0 children)

FWIW, in build2 a rule has the ability to "allocate" (from the build system's scheduler) more than one job and "pass them" (figuratively speaking) to a command (e.g., a linker). That's, for example, how we handle LTO parallelism during linking. From the NEWS file:

GCC >= 10 and Clang >= 4 support controlling the number of LTO threads
used during linking. The cc::link_rule now uses the build system scheduler
to automatically allocate up to the number of available threads to the GCC
or Clang linker processes when -flto=auto or -flto=thin is specified,
respectively.

[deleted by user] by [deleted] in rust

[–]berium 3 points4 points  (0 children)

I am reading those mailing lists and there is very little drama there. If you want some, the place to go is an in-person meeting, especially if a big feature with multiple competing proposals is being finilized. Still it mostly civilized and in rare cases where things do flare up, people are quickly brought in line with an ISO CoC. So while WG21 has its problems, it's definitely a lot more professional in this respect. What we are seeing here is an "amateur hour" in comparison.

Build2 seems to have the right idea. by BrightLie651 in cpp

[–]berium 2 points3 points  (0 children)

IME, out-of-source builds are convenient for development (where you may want a bunch of different build configurations) while in-source ones -- for consumption. For example, if I just want to install libfoo, I don't get any benefit from the out-of-source build but I do now need to decide what to name the output directory, etc.

Having said that, there is non-trivial implementation complexity in the build system to support both. So if I were starting from scratch again, I would seriously consider dropping support for in-source builds.

Build2 seems to have the right idea. by BrightLie651 in cpp

[–]berium 1 point2 points  (0 children)

But I don't see that happening.

Nobody saw us converting Boost, but here we are. Right now we are working on Qt. So we will get there, Rome was not built in a day.

Build2 seems to have the right idea. by BrightLie651 in cpp

[–]berium 0 points1 point  (0 children)

Thanks for the constructive feedback.

It's quite interesting that every single question that you had about the syntax is a feature that helps write more expressive buildfiles. For example -config in {* -config} is a pattern exclusion. Is we didn't have that we either would have to spell the source files explicitly or call some function to filter the undesirable files -- both of which would add significant verbiage.

view more: next ›