I'm now taking steps to get safe numerics integrated into the boost distribution. It's reminded me of a running complaint I have about using boost. a) When I use anything boost, I'm required to do two things: i) run b2 headers to create a forwarding header in the boost directory ii) include via command line or INCLUDE variable to boost root. b) If I want to use safe_numerics before it is included in the boost distribution, I have to place safe_numerics into it's expected destination in the boost hierarchy and run b2 headers AGAIN to make things match up. This is even more problematic in that b2 headers is not invoked "automagically" in such a way that people don't know it's there. To me, this just makes it harder to use / test any new library with boost without dragging in access to a bunch of stuff I may not want. It inhibits those without beam foo from running the tests etc. This is why I did things the way I did. Now I'm getting ready to add it to the boost distribution, I'll change this to do it the "boost way". Not so much because I think it's better but in this case, consistency is better than variety. But I'm still unsatisfied with the situation. It's part of the reason that boost is avoided when possible by many people. Isn't there a better way? I think there might be. Rather than sprinkling a bunch of forwarding headers around my file system - which are "sticky" and need to be updated from time to time, how about depending on the "INCLUDE" environmental variables available in gcc and msvc and clang. Using "some method", I would be able generate this variable via some sort of batch script - not too tough. And work as I do now. But a) the script would be re-run when ever I changed projects so that it "stuck" in my file system. b) It could be smarter - include only the boost include directories I'm actually using - thus avoiding accidently including surprising stuff. c) We have tools which figure out boost dependencies automatically so I don't think it would be a big stretch to do this automagically. d) If my project is "larger" and includes a bunch of stuff from other libraries, I could add these in as well. This would give my the concept of "library federation" where my app is linked to some list defined as part of the project. I'm sure this concept also sort of exists. e) my pet request would be that I could say: tool application.cpp ... >include environment output to generate the env output for all the target apps. Of course one could you * wild cards as well. This would let me create one set on includes for building/running my test suite and a different one for examples and a different one for my "real" application. I'll stop there so as to leave opportunity for discussion. Robert Ramey
AMDG On 08/11/2018 11:54 AM, Robert Ramey via Boost wrote:
I'm now taking steps to get safe numerics integrated into the boost distribution. It's reminded me of a running complaint I have about using boost.
a) When I use anything boost, I'm required to do two things:
i) run b2 headers to create a forwarding header in the boost directory ii) include via command line or INCLUDE variable to boost root.
b) If I want to use safe_numerics before it is included in the boost distribution, I have to place safe_numerics into it's expected destination in the boost hierarchy and run b2 headers AGAIN to make things match up. This is even more problematic in that b2 headers is not invoked "automagically" in such a way that people don't know it's there.
There's nothing stopping you from using safe_numerics outside the boost hierarchy with a separate -I option.
To me, this just makes it harder to use / test any new library with boost without dragging in access to a bunch of stuff I may not want. It inhibits those without beam foo from running the tests etc. This is why I did things the way I did.
If you're testing with `b2`, then you don't need to run `b2 headers` separately. If you're *not* testing with `b2` then there's nothing that requires a new library to be inside the boost hierarchy at all.
Now I'm getting ready to add it to the boost distribution, I'll change this to do it the "boost way". Not so much because I think it's better but in this case, consistency is better than variety. But I'm still unsatisfied with the situation. It's part of the reason that boost is avoided when possible by many people.
Isn't there a better way? I think there might be.
Rather than sprinkling a bunch of forwarding headers around my file system - which are "sticky" and need to be updated from time to time,
Normally, the "forwarding headers" are symbolic links which never need to be updated (and will break loudly when they do).
how about depending on the "INCLUDE" environmental variables available in gcc and msvc and clang. Using "some method", I would be able generate this variable via some sort of batch script - not too tough. And work as I do now. But
a) the script would be re-run when ever I changed projects so that it "stuck" in my file system.
How is this any easier than re-running `b2 headers`?
b) It could be smarter - include only the boost include directories I'm actually using - thus avoiding accidently including surprising stuff.
c) We have tools which figure out boost dependencies automatically so I don't think it would be a big stretch to do this automagically.
Okay, I'm confused here. If this is all handled automagically, then there's nothing absolutely nothing protecting you from "accidentally including surprising stuff"
d) If my project is "larger" and includes a bunch of stuff from other libraries, I could add these in as well. This would give my the concept of "library federation" where my app is linked to some list defined as part of the project. I'm sure this concept also sort of exists.
e) my pet request would be that I could say:
tool application.cpp ... >include environment output
to generate the env output for all the target apps. Of course one could you * wild cards as well. This would let me create one set on includes for building/running my test suite and a different one for examples and a different one for my "real" application.
I'll stop there so as to leave opportunity for discussion.
I admit that the current system isn't perfect, but your proposal seems even more complex and harder to use. In Christ, Steven Watanabe
On 8/11/18 12:50 PM, Steven Watanabe via Boost wrote:
There's nothing stopping you from using safe_numerics outside the boost hierarchy with a separate -I option.
Hmmm - wouldn't the require I mess with b2 switches? ouch.
To me, this just makes it harder to use / test any new library with boost without dragging in access to a bunch of stuff I may not want. It inhibits those without beam foo from running the tests etc. This is why I did things the way I did.
If you're testing with `b2`, then you don't need to run `b2 headers` separately.
Hmmm that's news to me. It seems that I've always had to do this but maybe that changed when I wasn't looking.
How is this any easier than re-running `b2 headers`?
It's not really easier - I just prefer the result. The redirecting is internal and "permanently" embedded into the file system.
b) It could be smarter - include only the boost include directories I'm actually using - thus avoiding accidently including surprising stuff.
c) We have tools which figure out boost dependencies automatically so I don't think it would be a big stretch to do this automagically.
Okay, I'm confused here. If this is all handled automagically, then there's nothing absolutely nothing protecting you from "accidentally including surprising stuff"
OK - I envisioned that only those boost libraries used by the target would be in the include list. One would then be be able to add any other "foreign" directories required by other libraries.
I admit that the current system isn't perfect, but your proposal seems even more complex and harder to use.
LOL - of course we disagree. Robert Ramey
AMDG On 08/11/2018 03:08 PM, Robert Ramey via Boost wrote:
On 8/11/18 12:50 PM, Steven Watanabe via Boost wrote:
There's nothing stopping you from using safe_numerics outside the boost hierarchy with a separate -I option.
Hmmm - wouldn't the require I mess with b2 switches? ouch.
Since safe_numerics is header-only, the only thing that you need to mess with is the include path.
To me, this just makes it harder to use / test any new library with boost without dragging in access to a bunch of stuff I may not want. It inhibits those without beam foo from running the tests etc. This is why I did things the way I did.
If you're testing with `b2`, then you don't need to run `b2 headers` separately.
Hmmm that's news to me. It seems that I've always had to do this but maybe that changed when I wasn't looking.
It was always supposed to work that way, and I think I got most of the wrinkles ironed out a long time ago. Currently, running `b2 headers` is necessary iff. you are working on a filesystem that supports neither symlinks nor junctions. This happens solely because the #include scanner in b2 misses some dependencies (specifically #include through a macro). I have always assumed that this situation where we have to fall back on making a full copy of all the headers is rare.
How is this any easier than re-running `b2 headers`?
It's not really easier - I just prefer the result. The redirecting is internal and "permanently" embedded into the file system.
b) It could be smarter - include only the boost include directories I'm actually using - thus avoiding accidently including surprising stuff.
c) We have tools which figure out boost dependencies automatically so I don't think it would be a big stretch to do this automagically.
Okay, I'm confused here. If this is all handled automagically, then there's nothing absolutely nothing protecting you from "accidentally including surprising stuff"
OK - I envisioned that only those boost libraries used by the target would be in the include list. One would then be be able to add any other "foreign" directories required by other libraries.
I admit that the current system isn't perfect, but your proposal seems even more complex and harder to use.
LOL - of course we disagree.
Ha. I suppose I am a bit biased, as I implemented most of the current system. Anyway, I'm not willing to spend my own time on implementing this, but feel free to take a stab at it yourself. It can, at least, be made to work for non-b2 consumers without breaking the current setup. In Christ, Steven Watanabe
On 8/11/18 9:11 PM, Steven Watanabe via Boost wrote:
LOL - of course we disagree.
Ha. I suppose I am a bit biased, as I implemented most of the current system. Anyway, I'm not willing to spend my own time on implementing this, but feel free to take a stab at it yourself. It can, at least, be made to work for non-b2 consumers without breaking the current setup.
Right - implementing "library federation" via generation of the "include" environmental variable wouldn't conflict with the current system. And my motivation is in large part to have something that doesn't depend on boost. I want to make it more convenient to incorporate non-boost libraries in my projects along side the boost ones in a simpler way. My motivation for the post is not to change b2 but rather perhaps someone else to create this thing that I think need. I think that boost depends more on b2 than it has to. And I think this makes it less attractive for users. Robert Ramey
On 08/11/18 20:54, Robert Ramey via Boost wrote:
I'm now taking steps to get safe numerics integrated into the boost distribution. It's reminded me of a running complaint I have about using boost.
a) When I use anything boost, I'm required to do two things:
i) run b2 headers to create a forwarding header in the boost directory ii) include via command line or INCLUDE variable to boost root.
b) If I want to use safe_numerics before it is included in the boost distribution, I have to place safe_numerics into it's expected destination in the boost hierarchy and run b2 headers AGAIN to make things match up. This is even more problematic in that b2 headers is not invoked "automagically" in such a way that people don't know it's there.
To me, this just makes it harder to use / test any new library with boost without dragging in access to a bunch of stuff I may not want. It inhibits those without beam foo from running the tests etc. This is why I did things the way I did.
Now I'm getting ready to add it to the boost distribution, I'll change this to do it the "boost way". Not so much because I think it's better but in this case, consistency is better than variety. But I'm still unsatisfied with the situation. It's part of the reason that boost is avoided when possible by many people.
Isn't there a better way? I think there might be.
Rather than sprinkling a bunch of forwarding headers around my file system - which are "sticky" and need to be updated from time to time, how about depending on the "INCLUDE" environmental variables available in gcc and msvc and clang.
Just for the record, gcc has CPATH and not INCLUDE. clang, probably, too, though I didn't check. Syntax is probably different from MSVC's INCLUDE, too. Also, I might be mistaken, but I thought there was a rather short limit on the env. variable length on Windows, which may come into play with variables like PATH or INCLUDE.
Using "some method", I would be able generate this variable via some sort of batch script - not too tough. And work as I do now. But
a) the script would be re-run when ever I changed projects so that it "stuck" in my file system.
b) It could be smarter - include only the boost include directories I'm actually using - thus avoiding accidently including surprising stuff.
c) We have tools which figure out boost dependencies automatically so I don't think it would be a big stretch to do this automagically.
d) If my project is "larger" and includes a bunch of stuff from other libraries, I could add these in as well. This would give my the concept of "library federation" where my app is linked to some list defined as part of the project. I'm sure this concept also sort of exists.
e) my pet request would be that I could say:
tool application.cpp ... >include environment output
to generate the env output for all the target apps. Of course one could you * wild cards as well. This would let me create one set on includes for building/running my test suite and a different one for examples and a different one for my "real" application.
I'll stop there so as to leave opportunity for discussion.
I'm not quite sure what exactly you are proposing. From my experience, when I was developing Boost.Log, I simply symlinked its tree into my Boost tree and had almost no problems with that setup. I didn't even have to run `b2 headers` whenever I added a new header to the library because `boost/log` was already a symlink to my `include/boost/log` directory. So in my case, this setup was mostly painless. I'm sure I wouldn't want to construct a setup based on environment variables because, as I usually do, I wouldn't want to modify my default environment this way. This would affect my work with other projects. Which would force me to create a special environment for working with Boost, which would just add more hassle.
On 8/11/18 1:12 PM, Andrey Semashev via Boost wrote:
Just for the record, gcc has CPATH and not INCLUDE. clang, probably, too, though I didn't check. Syntax is probably different from MSVC's INCLUDE, too.
I'm aware of this. I just didn't want to get into all the details.
Also, I might be mistaken, but I thought there was a rather short limit on the env. variable length on Windows, which may come into play with variables like PATH or INCLUDE.
apparently its 8K on windows and something greater then 64K on linux.
I'm not quite sure what exactly you are proposing.
From my experience, when I was developing Boost.Log, I simply symlinked its tree into my Boost tree and had almost no problems with that setup. I didn't even have to run `b2 headers` whenever I added a new header to the library because `boost/log` was already a symlink to my `include/boost/log` directory. So in my case, this setup was mostly painless.
Right - that's what we all do regardless of whether one does it by "hand" or via b2 headers.
I'm sure I wouldn't want to construct a setup based on environment variables because, as I usually do, I wouldn't want to modify my default environment this way. This would affect my work with other projects. Which would force me to create a special environment for working with Boost, which would just add more hassle.
Actually this is a big part of my motivation. I work on multiple projects. Boost stuff, non-boost C++, embedded systems, and fiddling with non-boost libraries. These use different tools and different compilers - even if C/C++. So I have to have different environment, path variables, etc for each one. I have a system which maintains all these is a "project configuration file" so I can easily suspend work on one project and switch to another. Takes about 1 second. So for me this is a natural way to do things. Robert Ramey
On 08/12/18 00:18, Robert Ramey via Boost wrote:
On 8/11/18 1:12 PM, Andrey Semashev via Boost wrote:
I'm not quite sure what exactly you are proposing.
From my experience, when I was developing Boost.Log, I simply symlinked its tree into my Boost tree and had almost no problems with that setup. I didn't even have to run `b2 headers` whenever I added a new header to the library because `boost/log` was already a symlink to my `include/boost/log` directory. So in my case, this setup was mostly painless.
Right - that's what we all do regardless of whether one does it by "hand" or via b2 headers.
I think I might have phrased my previous reply not clearly enough. I only symlinked `libs/log` and then ran `b2 headers` once, which created `boost/log` pointing at `libs/log/include/boost/log`. So the only thing one has to do is to put the library into the Boost tree somehow and then he can work with Boost, including his new library, as normal.
I'm sure I wouldn't want to construct a setup based on environment variables because, as I usually do, I wouldn't want to modify my default environment this way. This would affect my work with other projects. Which would force me to create a special environment for working with Boost, which would just add more hassle.
Actually this is a big part of my motivation. I work on multiple projects. Boost stuff, non-boost C++, embedded systems, and fiddling with non-boost libraries. These use different tools and different compilers - even if C/C++. So I have to have different environment, path variables, etc for each one. I have a system which maintains all these is a "project configuration file" so I can easily suspend work on one project and switch to another. Takes about 1 second. So for me this is a natural way to do things.
Yes, I also have projects that require a special environment, and I have scripts that set up that environment. I find that inconvenient because I must remember to run the scripts before starting to work on one of these projects and I must be careful to know which console has that environment and which doesn't. With Boost, I don't have to do that.
participants (3)
-
Andrey Semashev -
Robert Ramey -
Steven Watanabe