New Ubuntu test build for Seamly2D!

[Douglas]

@fidelhviegas

The code is actually quite easy to follow. It is well structured.

That’s debatable.

@fidelhviegas

Is this found on any branch? I tried to look for something related to this, but couldn’t find a branch that had these scripts.

Has nothing to do with any branch. They are a helper scripts to convert QMake to CMake. One is Qmake2Cmake the other is the Qt util used to build Qt6… pro2cmake.py.

[Evans]

@fidelhviegas

What are the essential components other than the Desktop one? Qt5 Compatibiliy mode?

I’ll try to answer for Windows, MSVC 2022 and Qt 6.9.1, but it should help you find the minimal configuration for Linux as well .

I think you should need nothing from “Qt Design Studio”, nothing from “Extensions” and nothing from “Qt Creator”. (If I’m not wrong the “Debug Symbols” in the “Qt Creator” section are to debug Qt Creator itself, not the softwares that you develop with it).

From the “Qt X.X.X” section you would need components for your compiler, as well as the “Sources” (it will help you get more information about the Qt functions, variables etc.) and the “Qt Debug Information Files”:

From “Additional Libraries”, I think we use only 3 of them:

• Qt 5 Compatibility module
• Qt Multimedia
• Qt Shader Tools

And from the “Build Tools” you may want those 3:

If you chose MSVC, you would have to DDL MSVC separately from their official website, if you selected MinGW, you could check one of the “MinGW” to install it directly from the Qt Maintenance Tool.

Please tell me if I’ve forgotten sthg, that way I can update my post for future developers

[Evans]

@fidelhviegas

Is this found on any branch? I tried to look for something related to this, but couldn’t find a branch that had these scripts. Or is this an offline thing you are working on?

Do you guys have a roadmap for the project?

I think we all agree that switching to CMake would be greeeeat, but we only did some testing of the scripts out there to do the conversion, without really taking the time to work on it, since, as @Douglas explained, it does require some manual adjustments to make them work.

You can find python scripts online doing part of the conversion, such as this one: Introducing qmake2cmake

@fidelhviegas

Is this found on any branch?

Since we didn’t really started the transition, I don’t think there is a branch with some new CMakeLists files replacing the .pri and .pro files. But if you want to try to compile Seamly using CMake, I think you could definitely fork the repo, create a branch and share it there, it would be amazing if you’re willing to give it a try ^^

[Douglas]

@Evans

If I’m not wrong the “Debug Symbols” in the “Qt Creator” section are to debug Qt Creator itself, not the softwares that you develop with it

That would seem to make sense. I would note that if @fidelhviegas starts with the minimum, he could always add any other components at a later time. The debug symbols are probably the last thing one needs to get the project to compile.

@Evans

From the “Qt X.X.X” section you would need components for your compiler, as well as the “Sources” (it will help you get more information about the Qt functions, variables etc

Don’t really need the sources unless you plan on compiling Qt. If you need to look at a specific Qt class source just Google it. I’ve got 3 MINIMAL Qt’s installed with NO source files… there’s nearly 3/4 million files that take up 1/2 my laptop’s SSD. On the other hand you may want the Qt Docs… athough to be honest - even though I have the docs - it’s quicker to just Google a class than than dish through the HTML docs to look up a class.

Shader tools are not needed… unless you plan on game programming or using Qt Quick. Seamly is not a game and does not use Qt Quick.

@Evans

I think you could definitely fork the repo, create a branch and share it there, it would be amazing if you’re willing to give it a try ^^

Agreed.

@Evans

You can find python scripts online doing part of the conversion, such as this one: Introducing qmake2cmake

Even though pro2cmake.py is a qt util, apparently it’s recomended to use QMake2CMake as it is adapted to be more suitable for general-purpose conversions.

[fidelhviegas]

@Evans

I think we all agree that switching to CMake would be greeeeat, but we only did some testing of the scripts out there to do the conversion, without really taking the time to work on it, since, as @Douglas explained, it does require some manual adjustments to make them work.

You can find python scripts online doing part of the conversion, such as this one: Introducing qmake2cmake

Hum… OK. I thought you were writing the scripts yourselves.

@Evans

Since we didn’t really started the transition, I don’t think there is a branch with some new CMakeLists files replacing the .pri and .pro files. But if you want to try to compile Seamly using CMake, I think you could definitely fork the repo, create a branch and share it there, it would be amazing if you’re willing to give it a try ^^

I have actually done that already. I don’t really have much time available now, but I will try to play around with it in the little time I have.

Thanks for the tips!

[fidelhviegas]

@Douglas

Don’t really need the sources unless you plan on compiling Qt. If you need to look at a specific Qt class source just Google it. I’ve got 3 MINIMAL Qt’s installed with NO source files… there’s nearly 3/4 million files that take up 1/2 my laptop’s SSD. On the other hand you may want the Qt Docs… athough to be honest - even though I have the docs - it’s quicker to just Google a class than than dish through the HTML docs to look up a class.

Shader tools are not needed… unless you plan on game programming or using Qt Quick. Seamly is not a game and does not use Qt Quick.

That’s what I thought. I will not fill my HD with unnecessary stuff. I rather look for the documentation online. As for the source code, I also don’t think I need it.

But, one thing I found is that I was working on my outdated fork that was last pulled in April.

Now I have everything set and will look into the qmake2cmake tool.

Thanks once again!

[fidelhviegas]

Hi again,

I have already installed the qmake2cmake and will play around a bit with it. Should I set the lowest Qt version to 6.2.4?

Thanks once again!

[fidelhviegas]

OK,

Just managed to convert the whole project to CMake with the following issues found on the qmake2cmake:

• it chokes on inline comments
• doesn’t support scopes, meaning all scopes need to be manually converted to CMake

I will look into the qmake2cmake source code to see if I can overcome these issues and automate as much as possible.

Other shortcomings mentioned on their website:

The following constructs also need to be manually converted:

• TEMPLATE = aux projects
• custom .prf files
• extra compilers
• extra targets

The tool is not a proper parser. It is more of a quick hack to convert qmake to cmake.

I will look into the convertion of the scopes that were throwing errors and do all the manual things that need to be done so that I can then start fixing all the cmake issues and make it work.

I will keep you posted.

Regards,

Fidel

[Douglas]

@fidelhviegas

I have already installed the qmake2cmake and will play around a bit with it. Should I set the lowest Qt version to 6.2.4?

I would say yes - for now. That’s what I’ve built with, and we just got the CI building yesterday afternoon runnning 6.2.4. I have 6.5.2 on my machine, but I haven’t built with it yet. If 6.5.2 works, I may then delete 6.2.4 so I will have room to install 6.9.1

@fidelhviegas

But, one thing I found is that I was working on my outdated fork that was last pulled in April.

Yeah… that’s quite outdated already… especially now that the main devleop branch is Qt6, and the fact that you won’t be able to compile your fork with Qt6. Several Qt5 modules were deprecated in Qt6 - including the XMLPatterns that contains all the classes for validating the xml files. We had to migrate to using the Xereces lib.

@fidelhviegas

The following constructs also need to be manually converted:

• TEMPLATE = aux projects
• custom .prf files
• extra compilers
• extra targets

Don’t think any of these apply to Seamly.

[fidelhviegas]

Hello again,

I’ve been reviewing the generated CMake files and noticed that quite a few manual adjustments are required, as the tool can’t handle certain aspects automatically. I’m planning to address this by creating custom scripts to automate the process as much as possible.

Here are some observations so far:

• When qmake is executed without parameters, it selects the .pro file with the same name as the current directory, or—if there’s only one .pro file—picks that one. If there are multiple .pro files, it displays the usage message.
• Regarding qmake2cmake_all, I’m not sure whether it processes all .pro and .pri files. From what I’ve seen, it simply generates a CMakeLists.txt for each folder corresponding to the .pro file named after that folder.

For .pro files in the same directory that aren’t matched to the folder name, how do you envision converting them? Should we create files with the same name but a .cmake extension?

For example, in share/translations, we have measurements.pro and translations.pro that are appended to lupdate.commands in Seamly2D.pro. These wouldn’t be converted to CMakeLists.txt unless they’re independent of Seamly2D.pro. As noted in measurements.pro, “it is a quick hack.” In cases like this, manual conversion is necessary because there’s no clear link showing they’re processed by Seamly2D.pro.

My thinking is that the first step should be to convert everything so it builds successfully. After that, we can move into a refactoring stage to clean up and improve the structure. That said, I’d like to get as close as possible to the intended structure from the beginning.

If you can provide some guidance on this, I can start moving toward that goal.

Look forward to your input.

Regards,

Fidel H Viegas

[Douglas]

@fidelhviegas

My thinking is that the first step should be to convert everything so it builds successfully. After that, we can move into a refactoring stage to clean up and improve the structure. That said, I’d like to get as close as possible to the intended structure from the beginning.

If you can provide some guidance on this, I can start moving toward that goal.

Right now my guidence would be to keep in mind what effect switching to CMake will have on the CI workflow as right now it’s predicated on using QMake. Also we need to clearly know how to reconfigure Creator for CMake , as I won’t be a happy camper if I can’t compile because I’m trying to figure out a kit config.

[fidelhviegas]

@Douglas

Right now my guidence would be to keep in mind what effect switching to CMake will have on the CI workflow as right now it’s predicated on using QMake. Also we need to clearly know how to reconfigure Creator for CMake , as I won’t be a happy camper if I can’t compile because I’m trying to figure out a kit config.

That’s exactly my concern as well. I am actually researching on how the Qt team did it on their own project. Here’s a video I am watching: Migrating from QMake to CMake | #QtWS22.

[Douglas]

@fidelhviegas

Here’s a video I am watching:

I came across that video too as I was looking for a way to convert from QMake. I suppose I should watch it.

[fidelhviegas]

Hello Douglas,

I have been a little busy on other issues, but I managed to look into the .pro and .pri files in order to understand them properly and be able to translate to CMake. I have also checked how to setup a project with CMake instead of QMake on Qt Creator.

The qmake2cmake tool was a quick hack to translate their own .pro and .pri files, and is does not handle some cases. But, to be honest, qmake itself also doesn’t follow their own specs. For instance, the following:

win32 { message("hello, world") }

is as valid as:

win32 {
    message("Hello, world")
}

as is the following:

win32 
{
    message("Hello, world")
}

The specs says that the ‘{’ should be on the same line as the condition and that the ‘}’ should be on a new line. This is just one of the things I noticed. There are others related to identifiers, and how some tools scan them.

I am going to adjust the parser to recreate a similar structure in CMake, so that it can later be easier to refactor.

The first thing I will do is have the parser successfully parse all files without choking. Once that is done, I will begin the translation.

I will kee you informed.

Regards,

Fidel H Viegas

[Douglas]

@fidelhviegas

The specs says that the ‘{’ should be on the same line as the condition and that the ‘}’ should be on a new line.

This is not a spec but rather a style guidline based on the (IMO stupid) K&R C styling for opening brackets. It’s only purpose was for “space saving efficency”… never mind it’s hard to read as the brackets don’t match up vertically. Especially given modern editors that display vertical lines matching brackets, and the fact we no longer deal with programs printed on reams of green and white striped tractor feed paper.

The “spec” calls for disregading whitespace… so it doesn’t matter where the brackets are. As far as qmake goes… it sees this:

win32{message(“Hello, world”)}

IMO the easiest to read, and most consistent styling is to put the opening bracket on the next line for all classes, methods, blocks:

win32 
{
    message("Hello, world")
}

QString AnchorPointTool::getTagName() const
{
    return VAbstractPattern::TagPoint;
}

if (parse != Document::FullParse)
{
    doc->UpdateToolData(id, data);
}

while (iMap.hasNext())
{
    ...
}

try
{
   formula = qApp->translateVariables()->FormulaToUser(variable->GetFormula(), qApp->Settings()->getOsSeparator());
}   

@fidelhviegas

The first thing I will do is have the parser successfully parse all files without choking. Once that is done, I will begin the translation.

[fidelhviegas]

@Douglas

The “spec” calls for disregading whitespace… so it doesn’t matter where the brackets are. As far as qmake goes… it sees this:

I was referring to the following description from the QMake Language specs:

Scopes consist of a condition followed by an opening brace on the same line, a sequence of commands and definitions, and a closing brace on a new line:

<condition> {
    <command or definition>
    ...
}

The opening brace must be written on the same line as the condition. Scopes may be concatenated to include more than one condition, as described in the following sections.

This is how tools other than qmake interpret. And the qmake2cmake will fail if you don’t follow this rule. The same goes for the KDevelop parser. They also expect this behaviour. It is only qmake that ignores white space in scopes. It will fail if you try to do this with variables. For instance, the following will fail:

myvar 
= test.cpp

It has to be on the same line followed by a newline character.

@Douglas

IMO the easiest to read, and most consistent styling is to put the opening bracket on the next line for all classes, methods, blocks:

I agree with you on this. I used to program in this style in C, but then I went to work for companies that used the left brace on the same line as the statement or declaration and I ended up switching to the dark side of the forces. I guess it is now more of a matter of habit than anything else.

The Seamly2D project, fortunately, has all the .pro and .pri according to the specs, and I guess all projects that use QMake follow the same. It is just that I found out by exploring QMake.

Anyway… thanks for your input! I will keep you updated on this.

Regards,

Fidel.

[Douglas]

@fidelhviegas

The Seamly2D project, fortunately, has all the .pro and .pri according to the specs,

I would assume that this in part due to the fact that at the start of the Seamly project the pro & pri files were automatically created wwth the Creator IDE Theoretically you could develop a project by never manually editing the project files.

@fidelhviegas

Anyway… thanks for your input! I will keep you updated on this.

Thanks. BTW… just an update on the minimum Qt ver - we bumped up the Qt ver to 6.5.3 in the CI.

[fidelhviegas]

@Douglas

I would assume that this in part due to the fact that at the start of the Seamly project the pro & pri files were automatically created wwth the Creator IDE Theoretically you could develop a project by never manually editing the project files.

Hum… OK. That makes sense.

@Douglas

Thanks. BTW… just an update on the minimum Qt ver - we bumped up the Qt ver to 6.5.3 in the CI.

OK, I’ll take that into account.

Thanks once again!