[Development] Fixing the DLL/shared/static mess

[Thiago Macieira]

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 
definition.

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 
released versions).

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: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120415/6fbfdd2b/attachment.sig>