Re: [boost] thoughts on logging library: orthogonal runtime configuration
Vicente Botet writes:
Hi Christian, [snip]
Configuring the above with a compiled library like boost serialization is an interesting task as well, that I definitely think should be addressed. could be that the flexibility decreases some in such a scenario, or it could be configued in site-config.jam or whatever.
Once the serialization library provide traces or log, if you want to use the serialization library with logs you should add a define at compile time e.g. -DBOOST_SERIALIZATION_LOG_ENABLE and link with the serialization logged variant e.g. -lboost_lserialization.
This is a good example of the need for compilers that output the code they generate based on templates. If they did that, the library writer could have an online service that spits out the final deliverable rather than users having to maintain different versions of a library. It is a slow and error prone process to rebuild a library/application as suggested here. Alternatively, service providers would have logging versions of their code available for users in the field, in effect eliminating the long and unproductive process of a rebuild. Because the code is built by the service provider rather than less experienced users, configuration confusion is mitigated. As the needs here are pressing, we hope the problems with the status quo will be addressed sooner than later. Brian Wood Ebenezer Enterprises www.webEbenezer.net
AMDG brass goowy wrote:
This is a good example of the need for compilers that output the code they generate based on templates. If they did that, the library writer could have an online service that spits out the final deliverable rather than users having to maintain different versions of a library.
I don't understand the advantage over preprocessor configuration. I don't really want to have to have a separate boost distribution every time I want a different configuration.
It is a slow and error prone process to rebuild a library/application as suggested here. Alternatively, service providers would have logging versions of their code available for users in the field, in effect eliminating the long and unproductive process of a rebuild.
How is this any better than just providing pre-built binaries. Unless different configurations are ABI compatible, switching configurations requires a re-build of all user code that depends on the library regardless of how the configuration is managed.
Because the code is built by the service provider rather than less experienced users, configuration confusion is mitigated. As the needs here are pressing, we hope the problems with the status quo will be addressed sooner than later.
In Christ, Steven Watanabe
----- Original Message ----- From: "brass goowy" <brass@goowy.com> To: <boost@lists.boost.org> Sent: Wednesday, April 09, 2008 10:40 PM Subject: Re: [boost]thoughts on logging library: orthogonal runtime configuration
Vicente Botet writes:
Hi Christian, [snip]
Configuring the above with a compiled library like boost serialization is an interesting task as well, that I definitely think should be addressed. could be that the flexibility decreases some in such a scenario, or it could be configued in site-config.jam or whatever.
Once the serialization library provide traces or log, if you want to use the serialization library with logs you should add a define at compile time e.g. -DBOOST_SERIALIZATION_LOG_ENABLE and link with the serialization logged variant e.g. -lboost_lserialization.
This is a good example of the need for compilers that output the code they generate based on templates. If they did that, the library writer could have an online service that spits out the final deliverable rather than users having to maintain different versions of a library. It is a slow and error prone process to rebuild a library/application as suggested here. Alternatively, service providers would have logging versions of their code available for users in the field, in effect eliminating the long and unproductive process of a rebuild. Because the code is built by the service provider rather than less experienced users, configuration confusion is mitigated. As the needs here are pressing, we hope the problems with the status quo will be addressed sooner than later.
I have never said that the "less experienced users" must rebuild a service provider library. An unhapplly some times they need to do it because even libraries done by experienced providers have bugs that appear only on the user field. Not this was not at all my purpose. The fact is that libraries can have some logs in the headers. So an application needing a login version of a given library (e.g. serialization), needs to link with the specific loging version (e.g -lboost_*l*serialization instead of -lboost_serialization) and possible to define something like -DBOOST_SERIALIZATION_LOG_ENABLE if the library contains some logs on the headers. Please note the difference between -lboost_lserialization and -lboost_serialization. I have use 'l' because the serialization library adds already a w for wide chars. I suspect that we are telling the same thing. Please could you be more explicit and say what is wrong? Best regards ____________________ Vicente Juan Botet Escriba
participants (3)
-
brass goowy -
Steven Watanabe -
vicente.botet