Hi Kris
Sorry for not responding earlier, I overlooked this mail. Are you able
to work on this still? I was thinking if you provide a patch to the
cmake branch (as it is) and it then shows CMake building and running
say the Python test-suite, then I could merge master into the branch
for finishing off before merging back to master.
Regarding the SWIG_LIB env variable, it does not need to be set for
the Windows executable only as the default Windows distribution has
swig.exe in the root directory and it looks for the Lib subdirectory
under swig.exe.
The default value of the SWIG_LIB is set to the location that it will
be installed into as set up by configure. So that is usually
/usr/share/swig/<version> and is controlled by the --prefix option to
configure. Run 'swig -swiglib' to see the default location. This
location does not change between the build and install as the binary
does not change. However, if the SWIG_LIB env variable is set it will
override the default location. During out testing we explicitly set
SWIG_LIB because we test before SWIG is installed.
The Appveyor builds are done on Windows and are done in the source
tree so swig.exe will find the Lib subdirectory and hence SWIG_LIB
does not need to be set. Travis is not used for Windows and also runs
the builds out of source and hence SWiG_LIB does need to be set, also
because SWIG is not installed during testing in Travis.
Hope that helps.
William
On 29 January 2016 at 07:00, Kris Thielemans
<***@gmail.com> wrote:
> Hi William
>
>
>
> Might be best to merge master onto the cmake branch then before doing any
> more work. I could do that in my fork only if you like.
>
>
>
> What do you mean with “working to some degree on Travis”? Compilation would
> work already :-) I’m guessing you’d want to have the test-suite working
> with some languages (Python only ok?)
>
>
>
> Could you please give some pointers for swig_lib? I’m confused when/how it
> is set, especially how it changes (if it does) between the build and install
> version of swig.
>
>
>
> Thanks
>
> Kris
>
> From: ***@fultondesigns.co.uk [mailto:***@fultondesigns.co.uk] On
> Behalf Of William S Fulton
> Sent: 28 January 2016 19:36
> To: Kris Thielemans <***@gmail.com>
> Cc: Thiel, Bjoern <***@mpibpc.mpg.de>; ,
> <swig-***@lists.sourceforge.net>
> Subject: Re: [Swig-devel] [CMake]
>
>
>
> Getting CCache to work is nice, but a secondary goal and probably too hard.
> I don't think I've ever had much luck getting it correctly when compiled
> with Visual Studio, and there are runtime problems with cygwin and some
> latest mingw versions have compile problems. It does work when compiled with
> mingw gcc cross compiler on linux, which is how I build it for the official
> release. Really the SWIG additions to ccache should be rebased on to the
> newer version of ccache which had a huge development spurt a few years after
> I took a snapshot of ccache. I think it has bug fixes fixes for Windows in
> it.
>
> If I see any patches for the cmake branch that show CMake working to some
> degree on Travis or Appveyor, I'll pull them into the branch.
>
> William
>
>
>
> On 13 January 2016 at 04:29, Kris Thielemans <***@gmail.com>
> wrote:
>
> Hi William
>
>
>
> Interesting. I had missed this branch.
>
>
>
> I couldn’t resist and tried this. It took me a few hours to get this to
> compile for both Cygwin-gcc and Visual Studio 2013. (I’ve used Cygwin’s
> bison in both cases but that’s irrelevant I guess).
>
>
>
> I needed
>
> - Some fixes to the CMakeLists.txt
>
> - Some fixes to CCache/ccache.h (some extra #ifdef stuff to cope
> with Visual Studio.
>
> - Major fixes to CCache/config.h.cmake.in
>
> - Addition of getopt and dirent implementations for Visual Studio
> (from http://www.two-sdg.demon.co.uk/curbralan/code/dirent and getopt from
> somewhere else)
>
>
>
> You can see my changes (w.r.t. original cmake branch) on
>
> https://github.com/KrisThielemans/swig/tree/cmake
>
>
>
> I haven’t been able to fix swig lib yet (i.e. I have to specify SWIG_LIB env
> variable). No idea how to do that really. The test-suite obviously also
> doesn’t work. There’s a few tricks that Bjoern used that aren’t in my
> commits either.
>
>
>
>
>
> Warning:
>
> There’s a change in ccache.h that might break non-CMake builds for Windows.
>
> In addition, the following would have to be defined by the normal configure
> for ccache :
>
> HAVE_SYS_FILE_H, HAVE_UNISTD_H, HAVE_UTIME_H, HAVE_DIRENT_H
>
>
>
> Obviously, this still doesn’t fix William’s desire to avoid (almost)
> duplicating *.in files and the list of files specified in Makefile.in vs
> CMakeLists.txt. I’d consider that longer-term goals.
>
>
>
> Kris
>
>
>
>
>
> From: William S Fulton
> Sent: 11 January 2016 20:23
>
>
>
> Bjoern
>
> We have a cmake branch called 'cmake' which needs some attention -
> https://github.com/swig/swig/tree/cmake. Here is an email thread you ought
> to take a look at wrt the background of cmake and swig:
>
> http://article.gmane.org/gmane.comp.programming.swig.devel/21611/match=cmake
>
> What I would only seriously consider is a maintainable CMakeLists.txt file
> that uses as much as it can of the autotool builds. That should include a
> list of files to compile within a file common to both automake and CMake.
> I'm hoping a common Includes/swigconfig.h.in file should also be possible.
> If you can provide patches to move the cmake branch in that direction, I'd
> love to merge it in as an alternative build system especially for Windows.
> It requires someone to see through the finishes touches to CMake support so
> that it is ready for prime time as no-one has so far been willing to do
> this.
>
> William
>
>
>
> On 11 January 2016 at 15:06, Thiel, Bjoern <***@mpibpc.mpg.de>
> wrote:
>
>
> Hi Kris,
>
> thanks for having a look at my code. I tried to get something like swigwin.
> That's why I forced static linking and left out the INSTALL target for now.
> Do you know a better way (switch or flag) to toggle dynamic/static linking
> from CMake?
> What's your suggestion for an INSTALL target?
>
> I considered using FindBISON.cmake but I didn't try because my own code
> seemed
> more transparent to me (of course).
> SWIG_CXX etc. get used in configuring swigconfig.h from swigconfig.h.in
> later (line 44).
> But your questions remind me of the fact that I should add some comments.
>
> Bjoern.
>
>
> ________________________________________
> From: Kris Thielemans
>
> Sent: Saturday, January 09, 2016 09:21
>
>
> To: Thiel, Bjoern; swig-***@lists.sourceforge.net
> Subject: RE: [Swig-devel] [CMake]
>
>
>>From: Thiel, Bjoern, Sent: 08 January 2016 14:29
>>
>> I have a CMakeLists.txt in order to build swig including Joel's Matlab
> module
>> with MSVC (Visual Studio) on https://github.com/bjoernthiel/swig .
>
> Hi Bjoern
>
> Great.
>
> questions:
> - wouldn't it be better to use FindBISON.cmake?
> - you're defining SWIG_CXX etc at the start. Are you actually using those?
> - why do you insist on replacing flags to static-runtime for MSVC? I'd leave
> this to the user.
>
> I'd add an INSTALL target.
>
> Of course, this doesn't include anything of the examples nor test-suite, but
> I'd vote for including this anyway as a first step. It at least allows
> developers to more easily experiment with changing SWIG.
>
> Kris
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Swig-devel mailing list
> Swig-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/swig-devel
>
>
>
>