April 2023 - Boost - lists.preview.boost.org

Re: [boost] Boost CI - a modest proposal
by Peter Dimov 30 Apr '23

30 Apr '23

Robert Ramey wrote: > I would suggest we throw the whole thing out and consider a different > approach. This approach would be more along the lines of that used by > CMake test server. Complete documentation of how CMake does it is > described in the CMake documentation. Basically it works like this. > > I run my CMake tests locally. This means that tests are not run on a server, but > on some users configuration. This spreads the load. Well, the main point of CI is to test your code on platforms other than your local one.

1 0

Re: [boost] Boost CI - a modest proposal
by Peter Dimov 30 Apr '23

30 Apr '23

John Maddock wrote: > It does however require discipline to not trigger useless builds (or cancel them > when they happen), ... For heavy CI workloads, setting up ccache correctly helps a lot in these cases.

1 0

Re: [boost] Boost CI - a modest proposal
by Andrey Semashev 30 Apr '23

30 Apr '23

On 4/30/23 18:37, Robert Ramey via Boost wrote: > the implementation of Boost CI follows the normal pattern for the > implementation of this functionality. This entails download the latest > version of the library to be tested and it's dependencies (or maybe all > of boost?) from the repo, Building everything from scratch, running all > the tests and logging the output there of. This is done for each > compiler / environment to be tested. Other than the raw console logs, > there is no presentation of the tests results (e.g boost test matrix). > > This is extremely unsatisfactory. > > a) It's ridiculously resource intensive. Rebuilding everything all the > time. Rebuilding everything is good. Incremental builds are fragile. > b) takes forever unless one has many more servers than we have. > > c) builds/tests even with the most trivial check-in. like adding a > period to a documentation page. You can mark commits to skip CI, if you want. > I would suggest we throw the whole thing out and consider a different > approach. This approach would be more along the lines of that used by > CMake test server. Complete documentation of how CMake does it is > described in the CMake documentation. Basically it works like this. > > I run my CMake tests locally. This means that tests are not run on a > server, but on some users configuration. This spreads the load. > > This means I run a special CMake target which takes the latest results > and posts them to a server. The results are not posted automatically - > I have to ask for it so it only happens when I know that a change is not > trivial. > > It also means that all configurations actually being used (and only > those configurations) are tested and the results logged. > > The server can than be queried to produce a table of results by > configuration, compiler, library, etc on demand. CMake people maintain > a basic server where one can post his results. But it's query facility > isn't really complete enough for boost needs. This facility would need > to be upgraded to boost requirements. Actually we have several > application which might serve as a starting point: my library_status app > which I use to produce a table of results and the app which produces the > boost library test matrix. > > All in all this would produce a system which would actually be useful. As a developer, I would like to know that the commit I pushed works on all configurations I care to support relatively soon (in a matter of minutes to hours), so that I can merge this commit to master. I do not want to wait until someone bothers to checkout and test this commit - on every supported system. You cannot expect this to happen any time soon, and you'll be lucky if you hear a bug report before a release deadline, when it is already too late to fix it.

1 0

Re: [boost] Boost CI - a modest proposal
by John Maddock 30 Apr '23

30 Apr '23

On 30/04/2023 16:44, Robert Ramey via Boost wrote: > the implementation of Boost CI follows the normal pattern for the > implementation of this functionality. This entails download the > latest version of the library to be tested and it's dependencies (or > maybe all of boost?) from the repo, Building everything from scratch, > running all the tests and logging the output there of. This is done > for each compiler / environment to be tested. Other than the raw > console logs, there is no presentation of the tests results (e.g boost > test matrix). I think you're wrong to call it "Boost.CI", most of what you're complaining about is the stuff that's outside our control - like the way Github actions run and so forth. > > This is extremely unsatisfactory. > > a) It's ridiculously resource intensive. Rebuilding everything all > the time. For github, I believe it can be configured to retain artifacts between builds and therefore perform incremental builds.... but, that is horrendously heavy on storage space, my expectation is that Github would throw us off for excessive usage! > > b) takes forever unless one has many more servers than we have. We have zero servers for CI, it's all Github etc. > > c) builds/tests even with the most trivial check-in. like adding a > period to a documentation page. Put [CI SKIP] in the commit message and nothing will build. > > I would suggest we throw the whole thing out and consider a different > approach. This approach would be more along the lines of that used by > CMake test server. Complete documentation of how CMake does it is > described in the CMake documentation. Basically it works like this. > > I run my CMake tests locally. This means that tests are not run on a > server, but on some users configuration. This spreads the load. > Well that's how we used to do things ;) Run it yourself, and hope for the best! I can tell you that I hated CI when it turned up, I mean what? Disturb my workflow and actually force me to change stuff! I can also tell you that a well set up CI system catches no end of small issues that I would never have spotted otherwise, also tests on platforms which I otherwise have no access to, and I simply would not be without it now! It does however require discipline to not trigger useless builds (or cancel them when they happen), and the need to update what you're testing and on what platforms periodically is a right pain, but I can also see why Github (for example) will need to deprecate and remove outdated distributions from time to time. So we all have to live with change I guess :( John.

1 0

Re: [boost] Boost.Compat
by Peter Dimov 30 Apr '23

30 Apr '23

Andrey Semashev wrote: > It doesn't really matter how many dependencies Boost.Thread adds. But it does. And you even need to build the library in this case.

1 0

Re: [boost] Boost::Regex support with ICU for unicode characters.
by John Maddock 30 Apr '23

30 Apr '23

> We are working with boost::regex library to have unicode support. I want to > form a regex for validating unicode characters so I'm trying this with > boost library. > > I am facing an issue with a boost library with ICU support so > please suggest me how to proceed with the boost with ICU support. PFA for > this. > > > 1. *has_icu_builds* is used to enable icu support. > [image: image.png] > > 2. on *b2 install* no icu is there, please let me know the procedure of how > to enable icu. > [image: image.png] ICU is an external dependency, we don't install it: it should already be installed prior to building Boost. Further, if you are using one of the last couple of Boost releases, then Regex is a header only library, and there is no need to build and install anything. You will however, have to link to ICU when you build your program. With regard to not matching specific text, if you can post the actual test code, I'll look at it. John.

1 0

Re: [boost] Boost CI - a modest proposal
by Vinnie Falco 30 Apr '23

30 Apr '23

On Sun, Apr 30, 2023 at 8:44 AM Robert Ramey via Boost <boost(a)lists.boost.org> wrote: > I would suggest we throw the whole thing out No

1 0

std vs boost
by Robert Ramey 30 Apr '23

30 Apr '23

When I'm writing library or user code, I often reach for a library component. Often, the similar/equivalent component exists in both the standard library component and the comparable boost component. I'm never confident about which to choose. Ideally I'd like a simple rule like "if you can choose between two components - prefer the standard library one (or Boost one) because ...". Is it possible to craft such a rule? My main criteria is mainly stability - once I've got something working I hate to be surprised when some "upgrade" breaks my code. Or is no longer supported. In other words, I don't want (and cannot) baby sit the application/library forever. Anyone have thoughts on this? Robert Ramey

1 0

Boost CI - a modest proposal
by Robert Ramey 30 Apr '23

30 Apr '23

the implementation of Boost CI follows the normal pattern for the implementation of this functionality. This entails download the latest version of the library to be tested and it's dependencies (or maybe all of boost?) from the repo, Building everything from scratch, running all the tests and logging the output there of. This is done for each compiler / environment to be tested. Other than the raw console logs, there is no presentation of the tests results (e.g boost test matrix). This is extremely unsatisfactory. a) It's ridiculously resource intensive. Rebuilding everything all the time. b) takes forever unless one has many more servers than we have. c) builds/tests even with the most trivial check-in. like adding a period to a documentation page. I would suggest we throw the whole thing out and consider a different approach. This approach would be more along the lines of that used by CMake test server. Complete documentation of how CMake does it is described in the CMake documentation. Basically it works like this. I run my CMake tests locally. This means that tests are not run on a server, but on some users configuration. This spreads the load. This means I run a special CMake target which takes the latest results and posts them to a server. The results are not posted automatically - I have to ask for it so it only happens when I know that a change is not trivial. It also means that all configurations actually being used (and only those configurations) are tested and the results logged. The server can than be queried to produce a table of results by configuration, compiler, library, etc on demand. CMake people maintain a basic server where one can post his results. But it's query facility isn't really complete enough for boost needs. This facility would need to be upgraded to boost requirements. Actually we have several application which might serve as a starting point: my library_status app which I use to produce a table of results and the app which produces the boost library test matrix. All in all this would produce a system which would actually be useful. Robert Ramey

1 0

Re: [boost] library usage statistics
by Peter Dimov 30 Apr '23

30 Apr '23

Robert Ramey wrote: > The basic question that occurs to me is "is this library worth maintaining and > keeping in boost". If dropping the library would break a lot of users code, > then the answer is an easy yes. If dropping the library would result in breaking > no code - the answer is an easy no. > Otherwise it's a judgement call we can argue about. But in order to do this we > need to know the answer the question: "How much code would be broken if > not in Boost. Hopefully this sheds light on this. There's probably a way to answer the question "how many Debian (Ubuntu, Fedora...) packages would be broken if we remove library X from Boost", but I don't know what it is.

1 0