3 ms·

this sounds like it could be really exciting if it takes off. the one thing that puzzled me was requiring the same compiler flags and preprocessor macros all th

by zem 7y ago

this sounds like it could be really exciting if it takes off. the one thing that puzzled me was requiring the same compiler flags and preprocessor macros all the way down a dependency tree - I'm not too immersed in the c++ world these days so I can't say for sure it is not an onerous requirement, but it seems like it could become one if you depend on a bunch of external libraries.

dekken_ 7y ago
IMO you can have general flags (-O3/-g3) for all compilation units(CU), but there should be the capacity to add any per CU
- uranusjr 7y ago
  It’s difficult in practice to distinguish between general and lib-specific flags, becuase one developer thinks is general does not always be considered the same by another, and you either need to magically read developers’ minds, or make a decision somewhere and leave a portion of your users grumpy. This is especially difficult for an ecosystem as established as C++ since there are too many interest groups all want different things. And more good luck if you don’t control the compiler—whatever you decide may end up wrong tomorrow because the compiler developers change their minds, and of course you take all the blame because everything works except when the user uses your tool.
wscott 7y ago
He is building a couple of things here. One is a way to package a C++ library and encode the dependencies. It is a subset of other similar tools and can be used as a bridge. So rather than have CMake load special code to talk to Conan, you can have Conan export a generic description and then CMake reads that description. This approach will let libraries work with multiple different build and/or packaging tools. The other is a 'drop dead simple' build tool. His build tool has these compile flag restrictions. But you could still build with CMake and add all kinds of extra requirements. However, for a library that you want to share, making it simple enough to work with the simple build tool is probably a good idea.
pjc50 7y ago
It's mostly an anti-madness requirement; there are lots of flags that are safe to vary by compilation unit, but there are some that aren't, so rather than attempt to enumerate them (which may vary by compiler), just enforce uniformity.

by zem 7y ago

dekken_ 7y ago

IMO you can have general flags (-O3/-g3) for all compilation units(CU), but there should be the capacity to add any per CU

uranusjr 7y ago
It’s difficult in practice to distinguish between general and lib-specific flags, becuase one developer thinks is general does not always be considered the same by another, and you either need to magically read developers’ minds, or make a decision somewhere and leave a portion of your users grumpy. This is especially difficult for an ecosystem as established as C++ since there are too many interest groups all want different things. And more good luck if you don’t control the compiler—whatever you decide may end up wrong tomorrow because the compiler developers change their minds, and of course you take all the blame because everything works except when the user uses your tool.

wscott 7y ago

He is building a couple of things here. One is a way to package a C++ library and encode the dependencies. It is a subset of other similar tools and can be used as a bridge. So rather than have CMake load special code to talk to Conan, you can have Conan export a generic description and then CMake reads that description. This approach will let libraries work with multiple different build and/or packaging tools. The other is a 'drop dead simple' build tool. His build tool has these compile flag restrictions. But you could still build with CMake and add all kinds of extra requirements. However, for a library that you want to share, making it simple enough to work with the simple build tool is probably a good idea.

pjc50 7y ago

It's mostly an anti-madness requirement; there are lots of flags that are safe to vary by compilation unit, but there are some that aren't, so rather than attempt to enumerate them (which may vary by compiler), just enforce uniformity.