On 12/14/2014 06:18 PM, tdeagan wrote:

Maybe MSYS2 is the easiest way to get everything running. This includes
qtcreator and most of the libraries. Actually only OpenCSG and QScintilla
are missing.

=> https://msys2.github.io/

Using the MXE builds with the Qt download does not work as they seem to
use different configuration regarding C++ exceptions so the libraries built
with MXE are not compatible with the MinGW shipped with Qt Creator.

ciao,
Torsten.

On 12/14/2014 06:58 PM, mx wrote:

Yes, there's a small change needed in version.pri:

It jumps into the Unix branch and executes date with the Unix parameters
causing it to wait for user input.

Changing:
win32-msvc*:!mingw-cross-env

To:
win*:!mingw-cross-env {

prevents that.

Otherwise I've just hacked the include/lib path into openscad.pro to see
if it's compiling.
That works so far that the welcome screen comes up, but when trying to
open the main window it terminates with a Qt error:

QWidget: Must construct a QApplication before a QWidget

ciao,
Torsten.

On 12/14/2014 08:19 PM, Scalpel78 wrote:

In Release mode it works now. I guess we do something wrong which does not
trigger the qFatal() on other platforms. So that's maybe a real issue and
not a problem with the native Windows build environment.

Install MSYS2 (I've used the 64 bit version)

• libs

$ pacman -Sy
$ pacman -S mingw-w64-x86_64-qt-creator
$ pacman -S mingw-w64-x86_64-boost
$ pacman -S mingw-w64-x86_64-cgal
$ pacman -S mingw-w64-x86_64-éigen3
$ pacman -S mingw-w64-x86_64-glew

• QScintilla

$ unzip QScintilla-gpl-2.8.4.zip
$ cd QScintilla-gpl-2.8.4/Qt4Qt5
$ /c/msys64/mingw64/bin/qmake.exe
$ export PATH="$PATH:/c/msys64/mingw64/bin"
$ mingw32-make.exe
$ mingw32-make.exe install

• OpenCSG

$ tar xvf OpenCSG-1.4.0.tar.gz
$ cd OpenCSG-1.4.0/src
change LIBS in src.pro: LIBS += -lglew32
$ qmake
$ mingw32-make.exe
$ mingw32-make.exe install
^ This installs to /usr/local - I've copied the files to the normal
lib folder (C:\msys64\mingw64\lib)

All that needs to the respective qmake files... but here it is just hardcoded
in openscad.pro... nothing that should go into any documentation.

win* {
FLEXSOURCES = src/lexer.l

• BISONSOURCES = src/parser.y

• BISONSOURCES = src\parser.y
• QMAKE_CXXFLAGS += -DNOGDI -DGLEW_STATIC -DOPENSCAD_QTGUI -Wa,--hash-size=2048 -O2
• QMAKE_CXXFLAGS += -I/c/msys64/mingw64/include
• QMAKE_CXXFLAGS += -I"c:/msys64/mingw64/include/eigen3"
• QMAKE_CXXFLAGS += -I"c:/msys64/mingw64/include/freetype2"
• QMAKE_CXXFLAGS += -I"c:/msys64/mingw64/include/harfbuzz"
• QMAKE_CXXFLAGS += -I"c:/msys64/mingw64/include/glib-2.0"
• QMAKE_CXXFLAGS += -I"c:/msys64/mingw64/lib/glib-2.0/include"
• QMAKE_LFLAGS += -I/mingw64/lib
• LIBS += -lintl -lglib-2.0 -lCGAL -lglew32 -lfontconfig -lfreetype -lharfbuzz -lmpfr -lgmp
  } else {

Add boost libs

isEmpty(BOOST_LINK_FLAGS):win* {

• BOOST_LINK_FLAGS = -llibboost_thread-vc90-mt-s-1_46_1 -llibboost_program_options-vc90-mt-s-1_46_1
  -llibboost_filesystem-vc90-mt-s-1_46_1 -llibboost_system-vc90-mt-s-1_46_1 -llibboost_regex-vc90-mt-s-1_46_1

• DEFINES += BOOST_STATIC
• DEFINES += BOOST_THREAD_USE_LIB
• DEFINES += Boost_USE_STATIC_LIBS
• #BOOST_LINK_FLAGS = -llibboost_thread-vc90-mt-s-1_46_1 -llibboost_program_options-vc90-mt-s-1_46_1
  -llibboost_filesystem-vc90-mt-s-1_46_1 -llibboost_system-vc90-mt-s-1_46_1 -llibboost_regex-vc90-mt-s-1_46_1
• BOOST_LINK_FLAGS = -lboost_thread-mt -lboost_program_options-mt -lboost_filesystem-mt -lboost_system-mt -lboost_regex-mt
  }

Comment out one line in glew.pri

win32:LIBS += -lglew32s

Comment out two lines in cgal.pri

win*: QMAKE_INCDIR += $$CGAL_DIR/auxiliary/gmp/include

LIBS += $$CGAL_DIR/auxiliary/gmp/lib/libmpfr-4.lib -lCGAL-vc110-mt-gd

"I have no doubt that either Qt or some number of its associated tools or addons
(e.g. MinGW) will have to be downgraded. "

On this point, everything we include needs to be tagged with a version and/or
build number. The world of Java is really good about this with Maven and C# has
NuGet, but I don't know if there's an equivalent for C++.

On 12/14/2014 10:18 AM, tdeagan wrote:

mx wrote

Ha!  I didn't take your */warning /*near seriously enough!  There are
definitely ominous omens surrounding this effort.  While installing msys2 on
my 'fresh' laptop it seemed to oddly hang during the download.  Then,
moments later, while printing an ornament for my festivus pole, I managed to
knock a can of hairspray off the shelf crashing it into the keyboard of the
laptop.  A really good solid kinetic transfer of energy.

The laptop worked for a little while, it hung, it worked, it hung hard, it
crashed.  It boots to recovery mode, recovery mode crashes.  It reboots and
boot manager denies the existence of any bootable media.  (and joy of joys,
it's a UEFI box, so futzing with the boot is a real can of fun  ).

Oh well, I wanted an SSD for the box in any case and now I'll get an early
christmas present.  If I'd known that setting up the environment for
building OpenSCAD in Windows involved starting from a virgin hard drive on
up, I might have hesitated...

But the motto that's gotten me through 20 years of software & hardware
development has always been "How hard can it be?"  So on to another learning
experience!

Cheers,
--tim

--
View this message in context: http://forum.openscad.org/Compile-OpenSCAD-on-Windows-tp10516p10542.html
Sent from the OpenSCAD mailing list archive at Nabble.com.