> Without access to their metrics though, it's hard to tell if they're continuing to gain meaningful traction or if their growth curve has plateaued. Some public data that could be used as proxy for traction: - Some…
Not really. Already hosted packages like Boost, Zlib, OpenSSL, ZMQ, Protobuf are packaged and hosted without changing a single line of their respective build, and with just a single conanfile.py to define the packaging.…
> But that is my whole point about Asio being split into smaller libraries such as Asio.Core, Asio.Network, and Asio.SerialPort. So you can use Asio.SerialPort without needing Asio.Network Yes, totally agree about it.…
The likelyhood of using both is not enough reason to embed them in the same SW component. Concerns have to be decoupled as mush as possible. It is even more likely that the user will use some serialization, and there is…
> That's backwards. A SerialPort library would depend on Asio since it defines sync and async streams and the utilities built around that. It seems bad design for a SerialPort library to reimplement those basic…
I partly disagree. Depending on boost, as-is, is still a problem from the point of view of engineering, and the example in the post is relevant. It shouldnt be necessary to retrieve hundreds of megabytes for…
Interesting project, yes, I also like the idea of having a common consensus for generating config.h files. Any idea why it is just C? Cause extending it to C++ seems trivial, and cannot find the rational about this.…
Great job, both taiga and managing the peak so well. Any tips about the infraestructure you are running? Relaying on any PaSS or managing yourself?
Not really, it is not trying to replace any build system. In fact it uses itself cmake as a build system, because ourselves were users of CMake, we like it, but mainly because CMake is by far the most popular build…
> Without access to their metrics though, it's hard to tell if they're continuing to gain meaningful traction or if their growth curve has plateaued. Some public data that could be used as proxy for traction: - Some…
Not really. Already hosted packages like Boost, Zlib, OpenSSL, ZMQ, Protobuf are packaged and hosted without changing a single line of their respective build, and with just a single conanfile.py to define the packaging.…
> But that is my whole point about Asio being split into smaller libraries such as Asio.Core, Asio.Network, and Asio.SerialPort. So you can use Asio.SerialPort without needing Asio.Network Yes, totally agree about it.…
The likelyhood of using both is not enough reason to embed them in the same SW component. Concerns have to be decoupled as mush as possible. It is even more likely that the user will use some serialization, and there is…
> That's backwards. A SerialPort library would depend on Asio since it defines sync and async streams and the utilities built around that. It seems bad design for a SerialPort library to reimplement those basic…
I partly disagree. Depending on boost, as-is, is still a problem from the point of view of engineering, and the example in the post is relevant. It shouldnt be necessary to retrieve hundreds of megabytes for…
Interesting project, yes, I also like the idea of having a common consensus for generating config.h files. Any idea why it is just C? Cause extending it to C++ seems trivial, and cannot find the rational about this.…
Great job, both taiga and managing the peak so well. Any tips about the infraestructure you are running? Relaying on any PaSS or managing yourself?
Not really, it is not trying to replace any build system. In fact it uses itself cmake as a build system, because ourselves were users of CMake, we like it, but mainly because CMake is by far the most popular build…