Hi!

On 12/13/2014 07:56 PM, Scalpel78 wrote:

No, unfortunately at this point there's no active developer working on Windows.
I'm doing the Windows builds but that's cross-compiling using MXE on Linux, so
any help would be awesome. Especially tracking down issues that only happen on
Windows is quite hard right now.
Currently the biggest help is MichaelAtOz putting lots of time into testing on
Windows, that's extremely helpful as otherwise Windows specific problems could
go unnoticed for quite some time.

Getting a native build on Windows is probably a bit of a challenge first as
nobody got as far as a fully working version. I think there are some threads
on both Github and the forum, the first I found is:

https://github.com/openscad/openscad/issues/431

I guess the first step would be to get the libraries compiled (maybe with some
replacements as mentioned in the issue discussion above).

The plan is to maybe make text() optional, that would mean the first try could
skip fontconfig, freetype and harfbuzz.

ciao,
Torsten.

On 12/13/2014 09:30 PM, Scalpel78 wrote:

I can help with my Windows 7 VM. OpenGL is not working there, but getting
the build environment up and running should be possible. I'm just not
interested in doing that for myself as I'm not planning to do development
on Windows in my spare time.
If someone else wants to join the effort, that would be great.

I guess there's two options to start. Either using MinGW / MSYS or using
the community edition of Visual Studio. At least from license point of
view that seems usable (but I might be wrong, I'm still confused after
reading though their mumbo-jumbo announcement).

In my opinion the first try could be VS2013 as that is probably more
attractive than a command line only MinGW build.

Right now, I don't know what the best option is, but we did talk about
that in the past, and the most promising idea was to provide a dev-package
as download with the pre-compiled dependencies.

So we could start with getting CGAL and it's dependencies (boost, gmp,
mpfr, ...?) compiled and maybe a simple test program running.
The github issue mentions that replacing gmp with mpir might help.

ciao,
Torsten.

tp3 wrote

I'd be interested in seeing what I can do to help.  I have an MSDN license
and have Visual Studio 2008 through 2013 already installed (VS2013 is a
weirdly different beast in a lot of ways.)

I'll start seeing if I can get the environment set up.  I'm primarily using
the SSIS and CLR db environments doing C# and VB at the moment, but there
shouldn't be any reason why I can't configure this (he says after spending
almost two weeks getting the new WCF-based Database Tools to add a stinking
web service reference in VS 2013...)

I'll start and report back.

--Tim

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

On 12/13/2014 10:35 PM, Scalpel78 wrote:

I think that should work too. What compiler is that using? I'm actually
using NetBeans and just run the GUI Designer when I need to edit the *.ui
files.

The GUI Designer should be included in the Qt download and that's all what's
needed. Maybe the add-in saves a click here and there when working on the GUI,
but OpenSCAD does not have too much GUI anyway ;).

ciao,
Torsten.

tp3 wrote

Here is the configuration from my machine.
http://forum.openscad.org/file/n10524/QTCompilers.png
Seems like it uses MinGW491's g++.exe

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

On 12/14/2014 12:04 AM, Scalpel78 wrote:

Hmm, that might make things easier as that's essentially the same
we use with MXE.
I wonder if we can just build the libs with MXE on Linux and drop
them into Qt Creator on Windows?

ciao,
Torsten.

I'm an experienced C++ programmer in the Windows environment, but my time is
wretchedly constricted at the moment. Nonetheless, if you could use some
guidance I'd be willing to pitch in.

On 12/13/2014 1:30 PM, Scalpel78 wrote:

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.

I got one step further after manually changing the files mentioned in that
.patch file.

Torsten, I don't quite understand what to do with the following. Could you
clarify what you mean here?

tp3 wrote

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

On 12/17/2014 07:17 PM, Scalpel78 wrote:

Hmm, right, I guess I missed the OpenCSG build script modification in my
log.

You mean the changes to the qmake files?

It's always mentioning the file, e.g. openscad.pro (main qmake file) or
glew.pri/boost.pri/... (imported by openscad.pro).

Essentially remove the lines starting with "-" and add those with "+".
It's basically a diff of the OpenSCAD directory after doing the changes
against the original github source.

ciao,
Torsten.

On 12/17/2014 09:46 PM, Scalpel78 wrote:

That looks like it's not finding the file as it's doing an out-of-source
build (which I think is the default).

What's the project setting "General -> Shadow build"?

That should just point to the folder with the OpenSCAD source.

ciao,
Torsten.

On Dec 18, 2014, at 13:02 PM, Scalpel78 frode@lillerud.no wrote:

Looks like the OpenCSG fixes didn’t make it to that page. It still tries to build examples and link with GLUT.

-Marius

On 12/19/2014 07:25 PM, Scalpel78 wrote:

Yes, if you have the OpenSCAD sources cloned and made the changes, you can
generate the full diff using "git diff > file.patch".

This could then be applied by "patch -p1 < file.patch" again on clean sources.

ciao,
Torsten.

On Dec 23, 2014, at 23:56 PM, RoyOnWheels royavery@hotmail.com wrote:

That’s all don through MSYS. That link is just informational.

-Marius

On Dec 31, 2014, at 03:12 AM, tdeagan tim@deagan.net wrote:

These are all related to the new Windows build system and we didn’t yet add them to .gitignore

Where do these come from? To my knowledge, these files should not be written to the src/ folder. If they’re written to the correct location, they’ll be ignored.

Once you switch you won’t switch back. The git workflow is, IMO, far superior to the centralized svn-style systems.
More recent svn versions do have better branching behavior then earlier though, so it’s not as much of a magic switch as it used to be.
A lot of corporate users tend to choose Mercurial over git. Not sure why.

-Marius

Hmmm.  Weird.  I found them in my clean master branch and in a seperate
clean clone I did of the OpenSCAD/OpenSCAD master branch.  But I didn't
check until after I did a build of each of these, so perhaps they're
emerging from the Win build somehow?

I'll do another clone of the master later today and check before and after/

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

Are they perhaps created by Lex & Yacc? Seem to recall that from the
distant past...

On 12/31/2014 10:38 AM, tdeagan wrote:

On Dec 31, 2014, at 15:10 PM, William W Martin wwm@wwmartin.net wrote:

They are, but they shouldn’t be created in the src/ folder, but in the root folder.
Sounds like a build glitch somewhere..

-Marius

On 12/31/2014 09:33 PM, Marius Kintel wrote:

Looks like those are coming from there:
https://github.com/openscad/openscad/blob/master/scripts/release-common.sh#L233

I'm not sure if that's still required.

ciao,
Torsten.

On Dec 31, 2014, at 15:40 PM, Torsten Paul Torsten.Paul@gmx.de wrote:

Interesting. Given that those shouldn’t even be used I don’t see why they’d be needed.
Unless there are other places those files are messed with..

-Marius