This is intentional. No need to export what is not used outside of the library. Every exported symbol increases dynamic linking time and the processing time during the linker stage (and yes this does matter, see further below). Also the size of the binary increases because every exported symbol is stored in the symbol table making the installer bigger.JdH wrote:I guess we could skip a huge amount of my changes, and it would still work. But: Some classes are exported/imported, and others classes are just inlined, or skipped entirely in the same header files.
And your point is? When you need a symbol then export it. If you don't need it you don't export it. No need to bloat the binaries and making linking harder than it already is.JdH wrote:I have not looked deep into the executable code, but it seems to me, that sometimes one would love to use a certain function or class, and it won't work out of the box, because that class/function isn't exported, even though other classes/functions from the same header are...
No proper api can declare away the dependency of the common on parser and parser on common. We need to call the parser from within common, the parsers needs to call some domain specific functions. This can't be changed.JdH wrote:Maybe it would be easier and cleaner to list all the functionality needed cross executables and design an proper api to excess those.
The reason why the parser library exists was already explained. The parser lib needs different compiler settings than the common lib because otherwise neither the linker nor the compiler could handle the compile process thanks to a compiler/linker limitation [1]. It would be possible to maintain the compiler setting on a per file basis but that is useless work because it doesn't solve the issue of linking and just add unnecessary burden of maintenance.
So what other possibilities do we have?
1) we split up common into a 'very common' and 'not so common' library. 'very common' contains only the code that parse and 'not so common' need but itself shouldn't of course need any symbols from 'not so common' and 'parse'. Great, now we have moved the circular dependency to the linking stage and if we're lucky we don't have duplicate symbols from linking to 'very common' when we meld together the static 'very common', static 'not so common' and static 'parse' into a dynamic 'common'.
2) Tell the linker that there will some symbols from parse available in the future step that he needs now to link the code of common. This can be done by a map file, a stub lib file or by the mentioned preprocessor comment statements I linked previously.
The current state IS a huge error prone mess. But randomly chopping the source code up to make it compile somehow doesn't make things better.JdH wrote:Maybe it is just me who thinks the current state of parser/common/executable-projects separation is a huge error prone mess.
[1] http://boost.2283326.n4.nabble.com/Spir ... 94042.html