[Development] Fixing the DLL/shared/static mess
thiago.macieira at intel.com
Sun Apr 15 15:33:26 CEST 2012
On domingo, 15 de abril de 2012 12.35.08, Uwe Rathmann wrote:
> Hi Thiago,
> my interest is of course to benefit as much as possible from the ideas
> and solutions of the Qt development
> and I believe the best way should be to organize my code and build
> environment like Qt libraries do.
> So please let me check your list what might be possible for Qwt:
Before that: why do you want to?
> > 1) where they are installed
> I wouldn't install Qwt into the same place where Qt is, because it works
> with different binary compatible installations of Qt.
> But of course it would be possible to do so for the same reasons you do
> it with a module like Qt SVG.
If installing in the same place as Qt -- mandatorily -- helps you by
simplifying the way that the library is found, then by all means do it. If you
enforce that, you don't need to do any finding, since it's always found next to
the QtCore for example.
> > 2) whether they use qt_module_config.prf or equivalent or a future
> > replacement
> I'm not sure if this would be possible for code outside the Qt source tree ?
Highly not recommended: private API, we might change it at any time.
> > 3) whether they follow Qt conding conventions -- including headers and
> > macros to be used, like QT_STATIC
> I have the same code base for Qt4 and Qt5 ( like the creator ) what
> might require some extra ifdefs, but in general it should be possible -
> as long as I'm aware of existing conventions.
Why do you want to?
> > 4) library and API naming
> similar to 4.
> > 5) development workflow and other Qt Project rules
> I don't believe, that I could develop in the same release cycles as the
> Qt library itself ( f.e I have no idea yet what it means to adopt Qwt to
> QML )
Release cycles are not part of the Qt Project rules. Each Qt module decides
when to make releases and when not to. The Qt Project will make an overarching
release containing the latest tested of each module, though.
The rules I'm referring to are:
- developing in Gerrit, bugs in JIRA
- following the Maintainer / Approver workflow
- same spirit fit and technical fit guidelines
- discussing and final decisions in mailing lists in @qt-project.org
> The only reason why I'm doing the Qwt project for such a long time ( >
> 10 years ) is because I only do it when I like to.
> If I had to sit down after my daily job only to keep schedules I would
> have given up long ago.
> But I guess this is similar for every project not sponsored by a company
> - what might happen to Qt some day too.
> > All Qt libraries are first-party: they come from the Qt Project.
> Do you believe it would make sense to develop a 3rd party library under
> the hood of Qt Project ?
That's self-contradictory. If it's under Qt Project, it's first party by
Both Qwt and Qxt would be welcome, just as Phonon once was and still is. I'd
prefer to see a full API review, just as what we did for some kdecore classes
that moved into Qt, but we can apply the rule of Qt4 compatibility too.
What the maintainership load will be, only you can tell. I really don't know
if those modules would attract attention and contributions, generating
reviewing load for you. I don't know whether the bug report rate would require
the Qt Project QA to require the Maintainer to take action (the maintainer is
responsible for the module being "always ready for beta" and the overarching
release requires the last released version to work with the all the other last
So this is really up to you and the question is: do you want to?
There's no shame in being a 3rd party library. Qwt has made a name for itself
and can continue doing that.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/development/attachments/20120415/6fbfdd2b/attachment.bin
More information about the Development