On Sunday 24 April 2011 21:40:25 Christian Stimming wrote: > Am Sonntag, 24. April 2011 schrieb Geert Janssens: > > > Recently some functions were introduces with the attribute > > > G_MODULE_EXPORT (Geert in r20591 and r20533). In short: No good, please > > > don't use that attribute inside gnucash. Why did you do this? > > > > Because that's what the GtkBuilder documentation suggested [1]. I'll > > admit I just blindly followed the advice given. I had no idea this had > > such an impact on the rest of the GnuCash library inter-dependencies. > > > > > Here's the issue: In gnucash, our internally "downstream" libraries > > > rely on *all* symbols being exported from the internally "upstream" > > > libraries. This is done by mingw's linker if and *only* if no symbol > > > at all was marked as being exported. As soon as at least one symbol > > > is manually marked as export, nothing except those marked symbols are > > > exported, > > > > Is that a design issue in the GnuCash code ? I mean should we normally > > explicitely decide which symbols to export an which not ? Or is this just > > bad advice on the gtkbuilder documentation page ? > > It is bad advice on the gtkbuilder doc page. Their statement is only half- > complete. Just from reading the statement, I agree your decision to use > that > > macro is correct. But their doc page is wrong. The wrong sentence is: > > When compiling applications for Windows, you must declare signal > > callbacks with G_MODULE_EXPORT, or they will not be put in the symbol > > table. > > Instead, a correct statement would be: > > When compiling applications for Windows and not using the auto-export > feature where all symbols are exported automatically, you must declare > signal callbacks with G_MODULE_EXPORT, or they will not be put in the > symbol table. If you are using the auto-export feature where all symbols > are exported automatically, you must not use the G_MODULE_EXPORT > declaration as the auto- export will work only if no symbol was declared > with that macro. > Ok, that clarifies it a lot.
> In terms of gnucash design: Yes, we could see it as a design decision of > gnucash. As we're not a library used by other people, we don't need to > spend any thinking on which functions/symbols should be exported to others > and which shouldn't. Hence, inside of our application (which happens to > consist of the executable plus a whole bunch of DLLs) we simply declare > everything as exported and that's it. Other projects that offer a library > interface to downstream projects will probably decide on a different > design, but we don't and shouldn't have to. > Yes, that makes sense as things are now. If we ever come to a point that we would want a libgnucash that can be used independently of a gnucash/cutecash application, we may have to revisit this item. For now, that's not needed. > This probably means we should just remove all occurrences of > G_MODULE_EXPORT again, not only undef'ing it as I did as a temporary > workaround. I will do so later today or tomorrow, unless someone else does it first. Geert _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
