Use CMake to build Slic3r XS

[lordofhyphens]

Working from the efforts done by @bubnikv and @CReimer

[lordofhyphens]

Going to work out most of the build server pain/suffering before I merge this.

[GilesBathgate]

+1 for this, a real benefit of this is that this will allow incremental builds instead of rebuilding all cpp files every time with Build.PL

I tried creating a qmake project for libslic3r (XS) simply so that I could do the build with make -j4. This was my qmake based build, although I agree CMake is more standard: https://github.com/GilesBathgate/Slic3r/tree/libslic3r-build

[lordofhyphens]

@GilesBathgate I've got the verbosity turned up
https://ci.appveyor.com/project/lordofhyphens/slic3r/build/job/sg6riu3s5nbsafxg

[GilesBathgate]

@lordofhyphens I wonder if it also needs C:\Strawberry\c\include. BTW I am basing this on guesswork, and various sources gleaned from the internet such as https://rt.cpan.org/Public/Bug/Display.html?id=116580

[lordofhyphens]

@GilesBathgate

Here's all the switches being used in the Build.PL compile of XS.cpp (the only holdout so far on Windows)

"-DVERSION=\"0.01\""
"-DXS_VERSION=\"0.01\""
-DBOOST_ASIO_DISABLE_KQUEUE
-DBOOST_LIBS
-DCONSERVATIVE
-DHAS_BOOL
-DNDEBUG
-DNOGDI
-DNOMINMAX
-DPERL_IMPLICIT_CONTEXT
-DPERL_IMPLICIT_SYS
-DPERL_TEXTMODE_SCRIPTS
-DSLIC3RXS
-DWIN32
-DWIN64
-D_GLIBCXX_USE_C99
-D_USE_MATH_DEFINES
-Dexprtk_disable_enhanced_features
-Dexprtk_disable_return_statement
-Dexprtk_disable_rtl_io_file
-Dexprtk_disable_rtl_vecops
-Dexprtk_disable_string_capabilities
-I"C:\STRAWB~1\c\include"
-I"C:\STRAWB~1\perl\lib\CORE"
-IC:\dev\boost_1_63_0
-Ibuildtmp
-Isrc
-Isrc/libslic3r
-O
-O2
-U__STRICT_ANSI__
-Wno-undefined-var-template
-c
-fno-strict-aliasing
-fwrapv
-mms-bitfields
-o
-s
-std=c++11
-xc++

And here's the command spit out with cmake.

-DBOOST_ALL_NO_LIB
-DCONSERVATIVE
-DHAS_BOOL
-DNDEBUG
-DNOGDI
-DNOMINMAX
-DPERL_IMPLICIT_CONTEXT
-DPERL_IMPLICIT_SYS
-DPERL_TEXTMODE_SCRIPTS
-DSLIC3RXS
-DSLIC3R_GUI
-DUNICODE
-DWIN32
-DWIN64
-DXS_EXPORTS
-D_UNICODE
-D_USE_MATH_DEFINES
-D_WIN32
-Dexprtk_disable_enhanced_features
-Dexprtk_disable_return_statement
-Dexprtk_disable_rtl_io_file
-Dexprtk_disable_rtl_vecops
-Dexprtk_disable_string_capabilities
-DwxUSE_UNICODE
-I
-IC:/strawberry/perl/lib/CORE
-O2
-O3
-c
-fext-numeric-literals
-fno-strict-aliasing
-fwrapv
-mms-bitfields
-o
-s
-std=gnu++11
@CMakeFiles/XS.dir/includes_CXX.rsp

Both of these commands have had some light trimming (the second one calls g++, not gcc), and I sorted the commands alphabetically (easier to diff that way).

[stuartpb]

Seeing as how this is the last issue blocking 1.3.0 from being released, can this be resolved easily (say, within the next week)? If not, it seems that this should be deferred to the next release so that 1.3.0 can ship.

[stuartpb]

For what it's worth, per #4168 (comment), I still don't see C:\strawberry\perl\lib\CORE being added to the include path (which was one of the paths mentioned to fix the similar issue described on CPAN).

EDIT: Never mind, it does appear that it's being added, somehow, though the c/include directory isn't in the final command.

[GilesBathgate]

If I understand correctly this PR has nothing to do with the being able to release, it's merely an improvement to the development tooling. I do agree that it is nice to have, but there is no reason for it to hold up the release.

[lordofhyphens]

cd /d C:\projects\slic3r\xs && C:\strawberry\c\bin\g++.exe   -DBOOST_ALL_NO_LIB -DHAS_BOOL -DNDEBUG -DNOGDI -DNOMINMAX -DSLIC3RXS -DSLIC3R_GUI -DUNICODE -DXS_EXPORTS -D_GLIBCXX_USE_C99 -D_UNICODE -D_USE_MATH_DEFINES -D_WIN32 -Dexprtk_disable_enhanced_features -Dexprtk_disable_return_statement -Dexprtk_disable_rtl_io_file -Dexprtk_disable_rtl_vecops -Dexprtk_disable_string_capabilities -DwxUSE_UNICODE @CMakeFiles/XS.dir/includes_CXX.rsp -O3 -DNDEBUG   -Isrc -Isrc/libslic3r -IC:/Strawberry/c/include -O -O2 -U__STRICT_ANSI__ -I -IC:/strawberry/perl/lib/CORE -fext-numeric-literals -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fwrapv -fno-strict-aliasing -mms-bitfields -std=gnu++11 -o CMakeFiles\XS.dir\XS.cpp.obj -c C:\projects\slic3r\xs\XS.cpp

@stuartpb

[GilesBathgate]

@lordofhyphens Does that location contain a file which in turn contains the definition for the thing which cannot be found in the compile error?

[lordofhyphens]

Not that I can tell.

…

On Jan 12, 2018 3:11 AM, "Giles Bathgate" ***@***.***> wrote: @lordofhyphens <https://github.com/lordofhyphens> Does that location contain a file which in turn contains the definition for the thing which cannot be found in the compile error? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4168 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB8CvD-hfjtcjCvda-fKN5n2-p09rllks5tJyHXgaJpZM4QDvpx> .

[GilesBathgate]

@lordofhyphens in perl.h we have PerlInterpreter but this is then defined

typedef struct interpreter PerlInterpreter;

The interpreter struct looks like this:

struct interpreter {
#  ifndef USE_5005THREADS
#    include "thrdvar.h"
#  endif
#  include "intrpvar.h"
/*
 * The following is a buffer where new variables must
 * be defined to maintain binary compatibility with previous versions
 */
PERLVARA(object_compatibility,30,	char)
};

So something is up with that typedef, the struct, or the intrpvar.h

[lordofhyphens]

It only does this on Windows, of course.

…

On Jan 12, 2018 9:34 AM, "Giles Bathgate" ***@***.***> wrote: @lordofhyphens <https://github.com/lordofhyphens> in perl.h we have PerlInterpreter but this is then defined typedef struct interpreter PerlInterpreter; The interpreter struct looks like this: struct interpreter { # ifndef USE_5005THREADS # include "thrdvar.h" # endif # include "intrpvar.h"/* * The following is a buffer where new variables must * be defined to maintain binary compatibility with previous versions */PERLVARA(object_compatibility,30, char) }; So something is up with that typedef, the struct, or the intrpvar.h — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4168 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB8CluHmDx6T5QDkBT8-V2mIQSi1Z58ks5tJ3uDgaJpZM4QDvpx> .

[platsch]

Any plans to continue with this?
I'd like to write some new test cases and it would be great if I could do it with catch...
which in turn would require the cmake stuff to be merged so I can PR my catch-branch...

Well, I could open a PR against the cmake branch to start with

[lordofhyphens]

I have yet to be able to figure out what is going on with the build on windows. I might have to work out a stopgap where windows builds use the old build.pl

…

On Feb 13, 2018 8:32 AM, "platsch" ***@***.***> wrote: Any plans to continue with this? I'd like to write some new test cases and it would be great if I could do it with catch... which in turn would require the cmake stuff to be merged so I can PR my catch-branch... Well, I could open a PR against the cmake branch to start with — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4168 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB8Cpo5m8gd7Bp42lqlNn4C-H6gT_6qks5tUZzrgaJpZM4QDvpx> .

[fivethreeo]

The issue mentioned on CPAN uses a patch for perl.h, found at the bottom of this thread: https://rt.cpan.org/Public/Bug/Display.html?id=121683

The patch should be in the latest perl. Maybe try addng -DHAS_STRTOUL and -DHAS_STRTOULL?

Cannot figure out where PerlInterpreter comes from to figure out what the problem is.

[lordofhyphens]

CMake is being used for the C++GUI efforts and the C++CLI.