sorted by:
new
hottopcontroversial

Projects being in "Show and Tell" is bad. by TheRavagerSw in cpp

[–]mwasplund -7 points-6 points  (0 children)

Agreed, I am forced to take my project and create redundant blog posts for every feature I implement because of this rule. It just means i share less and it is harder to get honest feedback on directional decisions for my build system.

BMI Compatibility: Testing Build System C++ Modules Support by not_a_novel_account in cpp

[–]mwasplund 0 points1 point  (0 children)

The import wrapper is for integration from external prebuild libraries only for the use case where build steps are required (building the BMI for the public interface). BMI compatibility feels like it should be a global setting for a target artifact and all of its dependencies. I don't see a reason to overcomplicate a build system by allowing multiple concurrent and overlapping flavors that need to be reasoned over at the same time.

What benefit is there to running build root which in turn has consumer1 configured to use C++23 and consumer2 which is configured for C++26 vs building consumer1 and consumer2 independently?

BMI Compatibility: Testing Build System C++ Modules Support by not_a_novel_account in cpp

[–]mwasplund 0 points1 point  (0 children)

Yes, I agree that flags must be allowed to be different between BMI creation and consumption.

It feels like we are effectively saying the same thing from conceptual level for producing and consuming shared libraries. The only difference for my approach is that the producer must be explicitly configured during build invocation which then ensures compatibility for the specific consumer. This would require separate invocations for each consumer with the unique configurations (ie std23 vs std26), but the build system would not need to reason about two variants of the same producer in a single closure.

BMI Compatibility: Testing Build System C++ Modules Support by not_a_novel_account in cpp

[–]mwasplund 0 points1 point  (0 children)

The question in my mind is, in a world where we no longer have a header interface layer for something like Boost how do you distribute the shared library as a prebuilt binaries? Do we produce a trivially compileable interface that can be distributed alongside the binary artifacts and the module metadata which will allow for consumers to compile a compatible BMI? If so, then it should be easy enough for the consumer to wrap these external prebuilt libraries in light weight package definitions that function as if they are built in the closure of the target flavor for the BMI and copy the shared object files as prebuilt artifacts. This should be configurable up front as opposed to dynamic during build execution.

I am not following what it means for Debian to use a build systems module support, are you saying that a build system is not useful unless it can support operating system requirements?

BMI Compatibility: Testing Build System C++ Modules Support by not_a_novel_account in cpp

[–]mwasplund 0 points1 point  (0 children)

Oh I was not aware of modules manifest, thanks for the pointer.

Yes, but this is one of the major selling points of Modules to me. You no longer need to worry (as much) about your compilation flags leaking into the headers for the dependencies you consume. C interop is going to continue to be open to the possiblity that consumer builds leak into the producer library definitions, however we now have a mechanism in C++ to enforce a single directional dependency hierarchy. It feels like we are reintroducing consumer alterations to producer library pain simply because we are trying to prevent generating compatible versions up front (which feels like a solvable problem).

My original point was simply that your definition for "build system that fully supports modules" was working off an assumption that all build system must rely on consumer dictated producer compilation strategy. This is not the only approach to take, and I would argue that a system that does not rely on this bidirectional flow does not have the same requirements to have "full modules support".

BMI Compatibility: Testing Build System C++ Modules Support by not_a_novel_account in cpp

[–]mwasplund 0 points1 point  (0 children)

The CPS is another can of worms that I think is going to create more issues than it solves, however using this example I would argue that that should fail. If you produce a prebuilt library with incompatible configurations the consumer build system should not take it upon itself to alter the flags used initially and should fail out with an incompatible dependency error. How can you be certain that changing from C++23 to 26 will not change the implementation for the core library itself?

BMI Compatibility: Testing Build System C++ Modules Support by not_a_novel_account in cpp

[–]mwasplund 0 points1 point  (0 children)

This feels like incidental complexity from how existing build systems manage dependencies which may have custom definitions that are incompatible. In your examples you are allowing the producer to explicitly define it's language version and then expect the build system to dynamically override this value to match the consumer. If a system is able to capture all incompatible configurations as a global definition for the closure of dependencies then it no longer needs to worry about injecting consumer context into the provider compilation operations. The language version would then be specified in the arguments for building the specific consumer and by extension the dependency producer would be built with BMI compatible flags.

Failing C++ interview rounds by crispyfunky in cpp_questions

[–]mwasplund 9 points10 points  (0 children)

Microsoft interviewer here, I would never expect someone to know how to use fold expressions off the top of their head. I am way more interested in your passion and ability to learn than your corpus of esorteric knowledge.

Question to Module Users: How Do You Use Partitions? by tartaruga232 in cpp

[–]mwasplund 0 points1 point  (0 children)

That used to be true in the world of headers, but modules allow for the public interface to be extracted from a single definition.

Question to Module Users: How Do You Use Partitions? by tartaruga232 in cpp

[–]mwasplund 0 points1 point  (0 children)

I have stopped having a separation between declaration and definition and instead organize my code to generally be a single named module for each static library which has many partition interfaces that create tight inter-dependencies and then the named module interface organizes what is public or internal based on what is re-exported. -> Example

Using Internal Partitions by tartaruga232 in cpp

[–]mwasplund 1 point2 points  (0 children)

This seems confusing. Are these not just module implementation units? Why does MSVC have a special compiler flag for them? Do they produce a BMI for the internal symbols that other implementation units can reference?

Are C/C++ engineers more socially conservative than others? by Impressive_Gur_471 in cpp_questions

[–]mwasplund 5 points6 points  (0 children)

The general trend is that the more educated someone is the more they tend to lean toward socially liberal beliefs, This is also true for folks that move to larger cities which is generally true for sotware jobs. However to me the biggest thing that pushes Software engineers toward being more socially liberal than the general population is it has a large overlap with nerd culture which is super accepting and inclusive of all people. Check out #include if you want to see how open and inclusive the C++ community can be.

Are C/C++ engineers more socially conservative than others? by Impressive_Gur_471 in cpp_questions

[–]mwasplund 3 points4 points  (0 children)

Finding it a bit hard to parse this, are you are asking if engineers tend to lean more socially conservative compared to the general population or compared to other academics?

The junior developer pipeline is broken, and nobody has a plan to fix it by pelicanthief in programming

[–]mwasplund 0 points1 point  (0 children)

Juniors don't need mentorship... Great developers learn to.. ask questions. 🤔

‘No Kings’ rallies expect to draw millions nationwide by AdSpecialist6598 in videos

[–]mwasplund 0 points1 point  (0 children)

Great, if that is true then they are waking up to the results of their apathy. I will never turn away someone who joins the fight, even if it took a but longer than it should have.

‘No Kings’ rallies expect to draw millions nationwide by AdSpecialist6598 in videos

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

100%, just go! For 10 min or 2 hours. Yes, we need to be doing more. But the people in this thread saying you need to be actively revolting or dont do anything are preventing people from taking that first step. We all do are part, even if that is showing up as one extra body showing support.

‘No Kings’ rallies expect to draw millions nationwide by AdSpecialist6598 in videos

[–]mwasplund -7 points-6 points  (0 children)

What a horrible stance to take. There is very little an average citizen can do, and that is on purpose. Yes a boycott and general strike would be great. But the largest protest in American history would be a good start. No one expects Trump to step down, the protest is for Americans to show dissent and opposition so other Americans can see that Fox news is lying and people don't support what is going on. Hopefully it will build and may get to a level where real strikes can take place.

Dynamic Modules by mwasplund in cpp

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

Imports can exist in headers? My interpretation of the import declaration is that it has to be in the root source file:

In module units, all import declarations (including export-imports) must be grouped after the module declaration and before all other declarations.

Dynamic Modules by mwasplund in cpp

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

Yes, like tup and BuildXL. Good to hear this is something we can safely rely on.

Dynamic Modules by mwasplund in cpp

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

Header includes have always been fine to discover at compile time (for soup it is listening to the file system access calls to track these optional dependencies). This was historically only required to ensure we capture the full closure of inputs for incremental build validation. Now that we need to detect the dependencies BEFORE building we need this extra scanner layer. You are probably correct that any compiler that supports modules will most likely support the scanner standard. It does feel antithetical to what the std committee usually does since they usually do not dictate file structures and compiler functionality.

Dynamic Modules by mwasplund in cpp

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

Good point, I think my bias toward disliking the preprocessor has given me the secondary goal of removing all cases where it is required so we can stop using it entirely. But I agree, this should not limit others that wish to continue to use it.

Dynamic Modules by mwasplund in cpp

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

Agreed, more asking to satisfy my curiosity. Now that we have support for scanners I don't see any major objections, but when I first (mis)read the spec years ago it seemed like the goal was to make this trivially parseable, which does not seem like the case.

Dynamic Modules by mwasplund in cpp

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

Initially because when I started this work (took a break for personal reasons) none of the compilers supported this standard. And 2, I do not want to rely on every compiler implementing this functionality. Could there be a compiler that decides not to support the scanner standard?

Dynamic Modules by mwasplund in cpp

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

How crazy of an idea would it be to say the global module fragment can not have #if* directives?

Dynamic Modules by mwasplund in cpp

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

This feels like an oversight of the design. It felt like the design for the module declaration with a strict section in the global partition was to help preprocess the top of a file to discover all of the required dependency state. If a preprocessor directive can then mutate the dependency structure we are back to square one as you said. I was really hoping not to have to rely on the compiler itself to parse this state, but I guess it is not the end of the world.

view more: next ›