Hi!
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?
br,
Jani
________________________________________
From: Development <development-boun...@qt-project.org> on behalf of Edward
Welbourne <edward.welbou...@qt.io>
Sent: Wednesday, April 3, 2019 12:32 PM
To: Alexandru Croitor
Cc: development@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:
C++/Qt (yay):
accessibilityinspector/
aglfn/ - Adobe Glyph List
corelib/qurl-generateTLDs/ (public suffix list)
glgen/ - Khronos OpenGL-related classes
lexgen/
plugintest/
unicode/
xkbdatagen/
gradientgen/ (also uses node.js) - QGradient presets
perl:
includemocs/ (no docs)
x86simdgen/
python:
edid/ - VendorTable
local_database/ - misnamed: locale_database
bash:
harfbuzz/
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.
For something.
On 2. Apr 2019, at 17:43, Edward Welbourne <edward.welbou...@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,
Eddy.
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
