[Development] Switching from create_changelog.pl to createchangelog for change log generation
jani.heikkinen at qt.io
Tue Apr 30 11:18:22 CEST 2019
It is time to create initial changes files for Qt 5.13.0. Unfortunately it seems we didn't manage to conclude this thread & make the decision which script is used to generate those.
For us it is same; we just run the script & push initial ones in gerrit. So which one we should use at this time? Should we just try the new one to see what kind of problems and complains it will generate?
From: Development <development-bounces at qt-project.org> on behalf of Edward Welbourne <edward.welbourne at qt.io>
Sent: Wednesday, April 3, 2019 12:32 PM
To: Alexandru Croitor
Cc: development at qt-project.org
Subject: Re: [Development] Switching from create_changelog.pl to createchangelog for change log generation
Alexandru Croitor (2 April 2019 14:02)
>> Just to throw some wood into the fire, because it's that kind of day,
>> technically we don't require Python or Go to build qtbase, yet we
>> require Perl. Hence +1 for using the perl script, because we need Perl
>> anyway : P
I note that the createchangelog script is not required to build qtbase.
Nor are the various scripts under qtbase/util/.
Survey of what these use:
aglfn/ - Adobe Glyph List
corelib/qurl-generateTLDs/ (public suffix list)
glgen/ - Khronos OpenGL-related classes
gradientgen/ (also uses node.js) - QGradient presets
includemocs/ (no docs)
edid/ - VendorTable
local_database/ - misnamed: locale_database
I have no clue:
integrity/qt.bod - whatever that may be (no docs)
Vaguely resembles JSON or QML.
Seems to be some kind of config.
On 2. Apr 2019, at 17:43, Edward Welbourne <edward.welbourne at qt.io> wrote:
> That sounds a lot like you just volunteered to maintain and review perl
> scripts. As one of those currently stuck doing so (mainly because
> few others will touch perl with a ten foot pole) I'd gladly replace all
> our perl infrastructure with python and replace the perl dependency.
Alexandru Croitor (2 April 2019 18:12) replied:
> Unfortunately I have minimal knowledge of Perl. But adding tools
> one-by-one in different languages doesn't seem to me the right
> solution either (from a maintenance perspective).
If we get too many different languages, that could be a problem, yes.
On the other hand, evolving is good and some tools are better for
particular jobs than others. I'm more concerned about tools having no
documentation of how to use them or what they're for (which I have run
into repeatedly - aside from the util/ things with no docs, several have
no more doc than a usage message and at least two only have docs because
I added them after I'd worked out how to use them in order to do so).
It would probably be a good idea to have a "permitted list" of languages
in which dev-related tools can be included in our source tree; and I
think it's pretty sensible to include
* python - we even have a team working on Qt for it
* go - Coin is written in it
If anything I'd leave off perl (and start porting scripts away from it)
because there are too few developers in this community willing to touch
it with a ten foot pole - and scarcely any that actively like working
in it. (FTR: I'd far sooner review or hack on a python script than a
perl script; but I end up being maintainer and reviewer for perl scripts
because I don't actually refuse and can make sense of perl.)
As for having "minimal knowledge of Perl", if it were a nice language to
work in I'd just encourage you to learn - but I'm not going to do that
to you, as I'd sooner port the existing infrastructure away from it.
One can write nice maintainable perl, but this isn't industry-standard
practice and I do not like maintaining what is,
Development mailing list
Development at qt-project.org
More information about the Development