[Interest] Porting Qt to our RTOS

Giuseppe D'Angelo giuseppe.dangelo at kdab.com
Thu Sep 27 18:03:55 CEST 2018


Il 27/09/2018 17:14, Roland Hughes ha scritto:
> 
> On 9/27/18 1:53 AM, Kim HartmanĀ  wrote:
>> I am investigating how to bring Qt to our INtime RTOS. The INtime Distributed RTOS runs on standard PC hardware as a multicore AMP OS (no SMP and not POSIX compliant). Currently the RTOS has only a text console output based on INT10 services. The RTOS is fully preemptive, with strict priority based scheduling, managed process services with rich IPC services. The development environment is tightly coupled with MS VC (2008 and on) with ANSI C and C++11 language support. The RTOS is very stable and been commercially deployed for decades. It lacks a means for graphical programming, mostly for industrial controls application. What is the means to port Qt to this RTOS? We're not intending on building out OpenGL ES 2.0 unless absolutely necessary. I've read some marketing materials about Qt on MCU, however the details seem very thin. It's not Windows, Linux, OSX, Android, QNX, Integrity, or VxWorks... how to go about getting this done?
> 
> The short answer is that you shouldn't.
> 
> The AGILE processes behind Qt development

1) This is an unproven and unwarranted assertion about whatever way Qt 
is developed. Since most of upstream development happens behind close 
doors at TQC, please refrain from making such statements, unless you 
happen to be working at TQC and can comment on the matter. And, even so, 
other development (e.g. the one *I personally* do on Qt) does not happen 
to be using agile processes.


2) This is a loaded sentence. Not only it's off-topic regarding the 
matter at hand ("how do I get Qt to run on another OS"); not only it's 
written to be provocative; but the _unwritten_ major premise of the 
syllogism is that agile processes are "bad" (for whatever reason). This 
major premise has not been established in this community.

And no, I don't care at all if agile development is better or worse than 
some other model; so do not bother me with 300 links about how agile has 
failed in the last 30 years of software development.

What I care about is not having loaded and off-topic sentences, with 
unwarranted claims, on this mailing list. I'm arguing about the logical 
fallacy, not the truth of the statement. Using that fallacy is 
disrespectful.


> means that a lot of shortcuts
> get taken and are allowed as long as the test-nothing automated test
> clears Jenkins. 

This is simply FUD, and it's offensive to whoever (like me) develops Qt 
as an external contributor and still cares about its quality.


> You should read up on the many discussions (one even
> within the past week) about critical bugs which rot until they are
> closed in typical OpenSource manner.

1) There's no such thing as "typical OpenSource manner". Would you 
kindly stop generalizing?

2) Qt is also a commercial product, with commercial support, and bugs 
fixed and prioritized (also) according to the commercial needs; so this 
statement is factually false.


> Qt is an incredibly heavy massive footprint. It gets heavier and more
> massive every day. You won't be porting "just a GUI." CAN-BUS, Serial
> I/O, SQL database, timers, yet another thread class, the absolutely
> worthless QML (which pretty much means you will need to port JavaScript
> as well.) Ah yes! In order to claim you have "ported Qt" you will also
> need to port WebEngine and all of the other Web stuff.

This is another blatant false statement, because you can port just the 
parts of Qt that you need, and even those can be further trimmed down 
using the feature system. (That's actually how you would do a port in 
the first place.)

There are already many parts of Qt that run only on a subset of all the 
platforms Qt has been ported upon, and there is no such thing as a 
"minimum set of things to support to say that Qt runs on a given platform".

My 2 c,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20180927/e0e04249/attachment.bin>


More information about the Interest mailing list