MSVC 2022 LibreCAD build

I am trying to compile under Visual Studio 2022 and I have everything converted to a .sln and I have a few files that are not found in the Git pull.

#include <QGridLayout>
#include <QPushButton>
#include <QSettings>
#include <QMessageBox>
#include <QTransform>
#include <QDoubleSpinBox>
#include <QSpinBox>
#include <QCheckBox>
#include <QComboBox>
#include <QLabel>

Is this a Qt library that I need? looks like they all have something to do with a Gear extension ?

Thanks.

Yes, Qt(currently, Qt-5.15) is needed.

For more details on dependency for building from source on Windows:

https://docs.librecad.org/en/latest/appx/build.html

Rahooty wrote

I am trying to compile under Visual Studio 2022 and I have everything converted to a .sln and I have a few files that are not found in the Git pull.

#include <QGridLayout>
#include <QPushButton>
#include <QSettings>
#include <QMessageBox>
#include <QTransform>
#include <QDoubleSpinBox>
#include <QSpinBox>
#include <QCheckBox>
#include <QComboBox>
#include <QLabel>

Is this a Qt library that I need? looks like they all have something to do with a Gear extension ?

Thanks.

I am following this in the manual:



it says to use "set LC_NSIS_FILE=nsis-5.4.nsi" in the case you're using "5.4" when the default is "5.2.x"

I am using version 5.12.12 and it looks like the default in the nsis-5.4.nsi is "5.15.2" ?


do I go ahead and use the "set LC_NSIS_FILE=nsis-5.4.nsi" in the "scripts/custom-windows.bat" ?

Thanks for your time.

I just installed Qt5.12
but I am still trying to get a grasp of the build structure... seems like there should have been a
nsis-5.15.nsi file in the "postprocess-windows" folder instead of sticking the 5.15.2 into the nsis-4.5.nsi

or am I lost lol.

I finally got a build with VS 2022 and it runs fine so far in the debugger until i print, then it throws an exception,  but i think that is a VS issue, it looks like others are getting the same when building to windows 11 (that's what i'm using)  others said if they target windows 10 they don't have the problem...

The switch to x64 is somewhat of a "size_t" nightmare (C4267)

x64 works with mingw for our continuous integration at github

Rahooty wrote

I finally got a build with VS 2022 and it runs fine so far in the debugger until i print, then it throws an exception,  but i think that is a VS issue, it looks like others are getting the same when building to windows 11 (that's what i'm using)  others said if they target windows 10 they don't have the problem...

The switch to x64 is somewhat of a "size_t" nightmare (C4267)

I'm assuming you are using mingw64 ?

Just curious,
How does Mingw handle something like this:


void Func1(short) {}
void Func2(int) {}
void Func3(long) {}
void Func4(size_t) {}

int main() {
   size_t bufferSize = 10;
   Func1(bufferSize);   // C4267 for all platforms
   Func2(bufferSize);   // C4267 only for 64-bit platforms
   Func3(bufferSize);   // C4267 only for 64-bit platforms
   Func4(bufferSize);   // OK for all platforms
}

We always support 64 bit Linux and macos.

What you are talking about is about coding errors. Code should express the underneath ideas, so raw types (short, int, etc) should be avoided without a good reason. C++11 and up makes explicit container size counting unnecessary in most cases.

Our code is always being reviewed and currently builds cleanly with c++17.

Rahooty wrote

I'm assuming you are using mingw64 ?

Just curious,
How does Mingw handle something like this:


void Func1(short) {}
void Func2(int) {}
void Func3(long) {}
void Func4(size_t) {}

int main() {
   size_t bufferSize = 10;
   Func1(bufferSize);   // C4267 for all platforms
   Func2(bufferSize);   // C4267 only for 64-bit platforms
   Func3(bufferSize);   // C4267 only for 64-bit platforms
   Func4(bufferSize);   // OK for all platforms
}

Exactly, what I am talking about are errors that my not be errors this time, but will for someone else.

this code is full of exactly what you recommended against, here is a example from lc_splinepoints.cpp on line (1218)



GetQuadPoints(i, &vStart, &vControl, &vEnd); first parameter is defined as an "int", and "i" that is passed to it is defined as a "size_t" and there is no guarantee that size_t won't be larger than int.

There are hundreds of these in the code giveing compiler warnings, some I think can be redefined, others can be cast int, but the problem seems to run deep for potential bugs

I suppose I'll just turn that compiler warning off if you guys good with it, it doesn't seem to be affecting my system?

Send it a pull request to fix it instead.

Conceptually, we are indexing the control points, and there's no need for negative numbers, so using signed int is unreasonable. Size_t is used because of containers in use.

Practically, it's not a bug yet, the index is not possibly up to int_max, because we need more work to be able to handle that many points.

Rahooty wrote

I suppose I'll just turn that compiler warning off if you guys good with it, it doesn't seem to be affecting my system?