drodri

> 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 companies using Conan in production can be seen in the committee for Conan 2.0 called the tribe: https://conan.io/tribe.html. That includes companies like Nasa, Bose, TomTom, Apple, Bosch, Continental, Ansys...

- The public repo for ConanCenter packages, got aprox +3500 pull requests in last year https://github.com/conan-io/conan-center-index/pulls. This doesn't count for contribution to the tool itself.

- https://isocpp.org/files/papers/CppDevSurvey-2020-04-summary... shows a 15% of adoption

- With +1600 subscribers the #conan channel in the CppLang slack is consistently ranked in the most active channels every month: https://cpplang.slack.com/stats#channels

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. The build systems of those libraries are heterogenous: Cmake, B2, perl+nmake... The build system is just wrapped by the conanfile.py. Those conanfiles can be also in a separate repository and retrieve sources from any origin as github, so not intrusive at all.

> 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. And I think I see your point now, agree also that libraries must implement concepts in a consistent way, and streams are indeed the way to go for reading/writing bytes. Maybe, what I am uncorfortable about is having that Asio.SerialPort explicitely coupled with async stuff like promises/futures.

Put it other way round, I think maybe the Asio.SerialPort should actually be something like HW.SerialPort, and this define a very low level library that acts just as an API to the HW, thus no promises here, as the OS does not handle that. Other languages like Node, Python could actually use and wrap this library to access the HW, and built their own async features. Then, it is perfect to have an Asio.SerialPort that builts both sync and async streams, using in the low level the HW.SerialPort. Maybe something in the line of: https://github.com/wjwwood/serial, but maybe with a more C++ style std::strings, streams (sync). Not sure, anyway, I will review my ideas, maybe I have to review my concepts about async and in which part of the stack should they be implemented, lets think 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 no point at all to implement serialization inside the library! Because then, also it is likely that the user want to make some CRCs to check message integrity, or cypher de message so lets embed such funcionality in the library too :)

I have developed and used code many times using a serial port (robotics, industry), and in many occasions such extra async framework or the streams are not used. I know they are quite convenient and useful for many many cases, but it is still a separate concern than implementing the low level "hardware" comunication, and thus deserve decoupling it its own component, exactly the same as serialization. In that way, when using Async for network sockets, the SerialPortHW concept wouldnt be involved at all, it would be in a different concept not included in the current project.

> 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 utilities.

IMO, the first layer could be a proper abstraction of the basic OS serial port functionality, without any notion of sync/async issues. Well, it will typically be sync. Keep it simple, it could be maybe just 2-6 files, depending on the approach to tackle different OSs. A common interface for open, config (baud, and the like), send, receive bytes, close. Lets call it SerialPortHW

Then, sync and async streams can be defined, or at least their interfaces and common functionality, which would be independent on any notion of physical transportation as SerialPortHW. Les call it AsyncStreams. In no way SerialPortHW has to depend on AsyncStreams (SerialPortHW->AsyncStreams), and the opposite is the same. They do not read logical, the concept "SerialPortHW" does not have implicit a requirement to know anything about async issues. If a function is slow to send bytes over the wire, it is slow, so what. It is fully functional, well defined, stand-alone and independent functionality that deserves its own entity.

Then, if the async serial port funcionality is desired, another component, lets call it AsyncSerialPort can be built composing/deriving AsyncStreams and SerialPortHW.

Sorry for the long response, I love arguing about SW design :)

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 implementing some serial-port functionality. The problem, of course it is not boost fault, or boost developers. Boost is fantastic. The problem is that is has been developed without environment tools like cargo, pip, maven, or whatever. If we had something similar for C and/or C++ before boost was developed, I'd bet we had a SerialPort lib, independent, portable, efficient, focused and well tested, and BoostAsio would just depend on it, instead of developing inside that logic.

Totally agree about that we need something as pip for C and C++, I think it is the point of the post.

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.

IMHO, most dev tools have practically no real need to distinguish between C and C++

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 system for C/C++ projects, especially multi-platform and open source projects. We don't say that other tools are not good, they are excellent tools too. But we cannot manage (at least now) to offer integration with them, so we chose just to use CMake. So biicode uses it as transparently as possible, allowing the user to configure things with the typical syntax we are used to with CMake in CMakeLists.txt files. You can use "configure_file", set "cmake_cxx_flags" or configure your "CTests".

Probably the post fails to explain that what biicode does is to generate basic xxx_vars.cmake files that contains useful variables about the project, and also a CMakeLists.txt (in case it is not defined by the user) which has some biicode macros that help to define the build. You might be able to read about it here: http://docs.biicode.com/c++/building.html

What biicode tries to do is to complement, and fill the voids that build systems were not designed for: - Storing code in a central server repository. Later retrieving code from the repository. Handling dependencies per project, not per system. - Managing different versions of dependencies, managing conflicts of dependencies and allowing conflict resolution. - Allowing easy discovery, retrieval and updating of dependencies. Offering web access to the code.

These are more or less the typical features of dependency managers (as PyPI-pip, NPM...). Biicode tries to go one step further by eliminating almost completely the packaging, the user does not have to think about libraries, setups, installs, updates... and this can be done thanks to the file based approach.

I hope it is better explained now. Thanks very much for your comment, do you think it is worth to edit the post with these ideas? Any further suggestions are very welcomed.