Simon,
In the description of the issue in JIRA I've pointed out why I don't like the
solution with an additional C/C++ wrapper. In short, I would have to compile
and pack such a lib for each OS, and then my users would have to deploy that
different per OS lib.
I'm not sure I understand your answer to my question. Why wouldn't the P/Invoke
approach work if I have all necessary symbols? What I'm asking is if there's
any way to emit only the exported inlines (for example, by combining
-fkeep-inline-functions and -fvisibility-inlines-hidden). This way I would get
my symbols and there won't be uncallable functions in the binaries.
Dimitar
On Tuesday, April 29, 2014 1:03 PM, Simon Hausmann <simon.hausm...@digia.com>
wrote:
On Tuesday 29. April 2014 01.30.24 Dimitar Dobrev wrote:
> I don't need invisible inlines either but some of them - such as
> QModelIndex::row() - are visible. Is there any way to emit just the visible
> inlines?
I think the pinvoke approach of creating bindings just won't work reliably
with C++ APIs that have inline functions then :(
But the ABI promise of Qt remains, so can't you create a library yourself that
basically contains the inline functions you need and otherwise references the
exported symbols from Qt? Your bindings will need to ship that library, but it
should continue to work with newer versions of Qt. (It just needs an update
when the inline functions change in a newer Qt version)
> On Monday, April 28, 2014 4:12 PM, Thiago Macieira
[...]
> `-fkeep-inline-functions'
> In C, emit `static' functions that are declared `inline' into the
> object file, even if the function has been inlined into all of its
> callers. This switch does not affect functions using the `extern
> inline' extension in GNU C90. In C++, emit any and all inline
> functions into the object file.
>
> DO NOT pass that flag. There's no need to bloat our binaries with functions
> that cannot be called (remember, we pass -fvisibility-inlines-hidden).
Ouch yeah, that makes it a no-go :)
Simon
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
