Minutes July 14 2010
Jeff Licquia (LF), Alan Clark (Novell), Stew Benedict (LF), Kay Tate (Novell), Jiri Dluhos (Novell)
- SDK ideas
Jeff: Last couple of calls we talked about LSB strategy. Alan, perhaps you can get with Robert, who had the most vocal opinion and we can touch back on that topic afterwards.
Alan: OK, will touch base with him and get back.
Jeff: Ran into an issue doing the updates with bundles, etc. But packages for 4.0 update are in the beta directory.
Jeff: Came across some information on gcc plugins. Seems like this could be a good alternative to using lsbcc. ISVs have some resistance to using a "different compiler", even though it's really just a wrapper.
Jeff: Do we think it would be the case that this is less of a change to the ISV build process than having to invoke lsbcc? Would they be more comfortable with that?
Kay: For the small guys this might be OK. For some of the big guys, the gcc version/config is probably too critical, that they might still resist any change to their build.
Kay: I can contact of some of the ISVs I have contact with and ask the question.
Jeff: Assuming this would work, and ISVs accept it, what sort of things would be want it to do? --lsb would go into full LSB mode, or perhaps a --lsb=strict, --lsb=relaxed (no lsb linker). What would ISVs want?
Alan: I worry about opening Pandora's box with --relaxed. How relaxed?
Kay: Perhaps we just limit "relaxed" to the dynamic linker.
Jeff: Another issue people have wanted is being able to pull in some system headers.
Kay: May want to post to the LDN forum and the lsb-discuss list.
Kay: Seems like we're weak in the marketing aspects of LSB.
Alan: Part of the problem is creating a story that's marketable. It's harder than it appears to be.
Jeff: Don't want to go into too many details, but we've acknowledged this internally and are working on something to address this.
Jeff: Anything else?
Jiri: Is this compiler plugin to be part of the SDK?
Jeff: Initially we'd support both the plugin and the current lsbcc.
End of Call