I'm using Common C++ 1.9.3 in my own project and I have a
a problem with the distribution of config.h, and the use of it in
the cc++ headers. In this way I got PACKAGE and VERSION
redefinition warnings (beacuse my own libraries defines it too).
I was thinking that the config.h file is for internal use within the
project (just including it in the .cpp files before includes of other
.h).
This problem I think that arise from the use of a single source
tree for cc++ in which the .h are full of #ifdef. Maybe the best
solution is to have separate trees ... and yes I know cc++ was in
this way.
Thanks a lot for your atention.
Jose Miguel.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
config.h is both needed and a nuisance. I would like to find a better way of dumping autoconf detected values for parsing and config options, or to hide them completely in interior code. One reason we never went for interior classes, however, was because that adds code overhead invoking members and functions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I'm using Common C++ 1.9.3 in my own project and I have a
a problem with the distribution of config.h, and the use of it in
the cc++ headers. In this way I got PACKAGE and VERSION
redefinition warnings (beacuse my own libraries defines it too).
I was thinking that the config.h file is for internal use within the
project (just including it in the .cpp files before includes of other
.h).
This problem I think that arise from the use of a single source
tree for cc++ in which the .h are full of #ifdef. Maybe the best
solution is to have separate trees ... and yes I know cc++ was in
this way.
Thanks a lot for your atention.
Jose Miguel.
There are a lot of use of configure in headers... perhaps we could make config.h shorter and without those defines...
I'll open a bug...
config.h is both needed and a nuisance. I would like to find a better way of dumping autoconf detected values for parsing and config options, or to hide them completely in interior code. One reason we never went for interior classes, however, was because that adds code overhead invoking members and functions.