<div dir="ltr">
Hi,
<br>
<br>Kevin Funk wrote:
<br><blockquote type="cite" style="color:rgb(0,0,0)">I think you're beating a dead horse here. The ship has sailed.
<br></blockquote>
<br>I am aware all of that <span class="gmail-moz-smiley-s1" title=":)"></span> Don't get me wrong. I don't want to turn the
tide and convince you to use Qbs instead of CMake. I'm just pointing
out: maybe take a look at this nuclear-powered ship prototype, even
tho' it hadn't left the docks. Have been asked about Qbs, so I explained my point of view. No reason to be
concerned :P<br>
<br><blockquote type="cite" style="color:rgb(0,0,0)">You'll be missing out on quite a bit of tooling which is implemented in KDE's
Extra CMake Modules framework:
<a class="gmail-moz-txt-link-freetext" href="https://github.com/KDE/extra-cmake-modules">https://github.com/KDE/extra-cmake-modules</a>
<br> (part of that is all the translation handling)
<br>It may be hard to accomplish with CMake.
<br></blockquote>Yeah, I have been looking at ECM. It's all well done etc, but what I
meant by "components" are components like QML components. I've been
using CMake in my projects for many years, so I can compare the two. I'm
not a Qbs fanboy. CMake has its pros and advantages, but its language
lacks constructs like structures/classes/records, inheritance etc (don't
want to start another offtopic here, but I think we can all agree that
CMake language is a bit limited and its syntax is quaint...).
<br>
<br>Then, I have deliberately written <b class="gmail-moz-txt-star"><span class="gmail-moz-txt-tag">*</span>something like<span class="gmail-moz-txt-tag">*</span></b> Qbs (not just Qbs). I
mentioned Qbs has some issues (I didn't want to elaborate, to not make
an offtopic, but here we are...), most important of which is that it
isn't built on top of QQmlEngine and it's not QML, but merely a QML
dialect. Imagine a proper QML-based build system, into which you could
import standard QML extensions. Integrity is something we're missing
nowadays. Still Qbs product definition files are clean and unmatched in
terms of readability, thus I think it paves the way for next-gen build
system, which will eventually replace CMake.<br>
<br>I hope Qbs controversy is clarified now <span class="gmail-moz-smiley-s1" title=":)"></span>
<br>
<br>Regards,
<br>Michal
</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">sob., 15 lut 2020 o 14:11 Kevin Funk <<a href="mailto:kfunk@kde.org">kfunk@kde.org</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thursday, 13 February 2020 11:00:27 CET Michal Policht wrote:<br>
> Yeah, I neglected translations a bit... I am going to implement adequate<br>
> Qbs module for extracting translations.<br>
<br>
Heya,<br>
<br>
> When it comes to Qbs, it's not dead. Community has taken over the<br>
> project, there's active development and recent version was released just<br>
> 44 days ago.<br>
> <br>
> We migrated from QMake to Qbs, when it was still supported by Qt Company<br>
> and promoted as official build system for Qt 6. Thus we assumed Qbs is<br>
> the future. We've found that Qbs has some issues (like every software),<br>
> but in overal it's very capable and powerful piece of software. It also<br>
> provides much faster builds on Windows. I wish more people would give it<br>
> a try before burying the project, to at least see the potential. With<br>
> something like Qbs we could create a build framework with reusable<br>
> components, so that each KDE subproject could benefit from it and become<br>
> naturally integrated.<br>
<br>
I think you're beating a dead horse here. The ship has sailed. <br>
<br>
You'll be missing out on quite a bit of tooling which is implemented in KDE's <br>
Extra CMake Modules framework: <br>
<a href="https://github.com/KDE/extra-cmake-modules" rel="noreferrer" target="_blank">https://github.com/KDE/extra-cmake-modules</a><br>
(part of that is all the translation handling)<br>
<br>
There's also no support for building QBS projects on KDE's CI:<br>
<a href="https://build.kde.org" rel="noreferrer" target="_blank">https://build.kde.org</a><br>
<br>
> It may be hard to accomplish with CMake.<br>
<br>
What exactly? I mean it's all there already.<br>
<br>
> Regards,<br>
<br>
PS: Qt's CMake-based build system just got merged into qtbase dev branch a few <br>
days ago.<br>
<br>
Regards,<br>
Kevin<br>
<br>
<br>
> Michal<br>
> <br>
> > El dilluns, 3 de febrer de 2020, a les 17:57:24 CET, Michal Policht va <br>
escriure:<br>
> >> Hello there,<br>
> >> <br>
> >> CuteHMI (<a href="https://cutehmi.kde.org/" rel="noreferrer" target="_blank">https://cutehmi.kde.org/</a>) has been moved to kdereview.<br>
> > <br>
> > It has no Messages.sh for translation extraction.<br>
> > <br>
> > Any particular reason you're using a dead build system none of our<br>
> > projects uses?<br>
> > <br>
> > Cheers,<br>
> > <br>
> > Albert<br>
> >> <br>
> >> CuteHMI is meant to be a set of tools and components that help one to<br>
> >> create QML-based HMI/SCADA software.<br>
> >> <br>
> >> The project has been started few years ago, because I couldn't find any<br>
> >> open-source, QML-based HMI/SCADA framework I could put my things into.<br>
> >> <br>
> >> Regards<br>
> >> <br>
> >> Michal Policht<br>
<br>
<br>
-- <br>
Kevin Funk | <a href="mailto:kfunk@kde.org" target="_blank">kfunk@kde.org</a> | <a href="http://kfunk.org" rel="noreferrer" target="_blank">http://kfunk.org</a></blockquote></div>