I think there's another reason to not use the plural "symbols" in the
stanza name as has been suggested. Because we're actually talking about
the end result of how individual symbols are named:
some_new_function@@MIR_PLATFORM_9.2
some_new_function@MIR_PLATFORM_9.1 # Slightly less new
So ideally each one should not be named "*symbols*". Even using the word
"symbol" is redundant. We're just adding version suffixes really, so
keep that in mind.
On 31/08/15 10:34, Daniel van Vugt wrote:
Although you can easily avoid being wordy and have the best of both worlds:
MIRPLATFORM_9.0.16
MIRPLATFORM_9.0.17
On 31/08/15 09:57, Daniel van Vugt wrote:
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
