I've considered using your suggested approach but also been using an
arguably cleaner solution for around the past year[*]. If you look in
src/client/symbols.map you will find:
MIR_CLIENT_9.1 { # New functions in Mir 0.15
It's no less foolproof than what you suggest, but has the added benefit
of not over-growing symbol names embedded in the binaries.
Given that symbol name length is a major cause of binary bloat in C++
already, that's something to consider...
[*] Past year but you won't find many traces of it because we keep
deleting the entries with comments when they get subsumed by major ABI
bumps.
On 28/08/15 23:46, Alan Griffiths wrote:
The current approach to naming stanzas in the symbol maps leads to a
potential for mistakes. For example, src/platform/symbols.map has the
following stanzas:
MIRPLATFORM_9 {
...
}
MIRPLATFORM_9.1 {
...
} MIRPLATFORM_9;
It is far from obvious when adding a symbol whether it should be added
to MIRPLATFORM_9.1 or to a new MIRPLATFORM_9.2. As it happens
MIRPLATFORM_9.1 was created after 0.15 was branched so that is the
"right one". But it isn't obvious: If MIRPLATFORM_9.1 had shipped in
0.15 then MIRPLATFORM_9.2 would be right.
I don't know of any reason why we name stanzas this way except "tradition".
What does the team think of using this instead?
MIRPLATFORM_9_new_symbols_from_0.16 {
...
} MIRPLATFORM_9;
And after we branch release 0.16 it is clearer we should add:
MIRPLATFORM_9_new_symbols_from_0.17 {
...
} MIRPLATFORM_9_new_symbols_from_0.16;
When the ABI breaks we consolidate as before.
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
