[Swig-devel] using travis-ci to test matlab support

Post by Michael Tesch
Hello,
I'm working on the matlab module, and am wondering what would be the
best way to provide the travis-ci testing support.
The problem is that there doesn't seem to be a reasonable way to run
MATLAB from within travis-ci.

What is the problem here? Is there something different to all the other
languages?

If this testing is to work in Travis, MATLAB needs installing from
somewhere, most likely via a ppa? What did you have in mind?

Post by Michael Tesch
Would it be enough, as far as travis-ci is concerned, to simply
compile & link the wrapper files for the tests using the same flags
that MATLAB would?

The wrappers are usually compiled with the default compiler flags.
However, some language modules will compile with the flags that
extensions are expected to be compiled with. If you are going to use
non-default compiler flags, you'll need to pull the compile and link
flags out of the configuration for the target language. Usually this is
done via pkg-config or similar tools such as python-config and
php-config during configure time. Anything else will lead to a messy
configure.ac script which will need lots of platform and compiler
specific code.

I'd like to help you get this set up correctly sooner rather than later.
Getting the build system correct is essential for me to consider merging
into master. Once you have it working, I'll take a look for you.

William

Kris Thielemans

2014-12-08 21:12:09 UTC

From: William S Fulton, Sent: 08 December 2014 20:22

What is the problem here? Is there something different to all the other
languages?

I don't know travis-ci, so I have no idea what specifically is going wrong.

Post by William S Fulton
If this testing is to work in Travis, MATLAB needs installing from
somewhere, most likely via a ppa? What did you have in mind?

I'm afraid this is impossible. MATLAB is commercial (and expensive). I think
the only thing that could be done is to let travis-ci run the MATLAB tests
by those people who happen to have a MATLAB installation.

Post by Michael Tesch
Would it be enough, as far as travis-ci is concerned, to simply
compile & link the wrapper files for the tests using the same flags
that MATLAB would?

Pkg-config etc have no idea about MATLAB.

I guess this will be a stupid question, as I haven't checked travis-ci, but
from your comment I suppose it runs completely independent from SWIG's
configure process? That would create complications as it'd be hard to
guarantee that the the travis-ci build will use the same options as the
configure (there could be 2 matlabs for instance). Possibly the configure
process could create the files necessary for travis-ci?

Currently, the test-suite in SWIG uses configure to find where MATLAB is,
and then compiles the wrappers with "mex", which is a script that comes with
MATLAB that calls the actual C++ compiler but with appropriate flags. Is
this not reusable?

Alternatively, you can find out (by running mex) what flags to use and then
just call the C++ compiler yourself. You might have seen the CMakeFiles.txt
stuff that I sent round which does this. It's quite tricky to do this in
general (depends on MATLAB version etc etc).

Post by William S Fulton
I'd like to help you get this set up correctly sooner rather than later.
Getting the build system correct is essential for me to consider merging
into master. Once you have it working, I'll take a look for you.

Thanks for your offer. Unfortunately, the commercial nature seems to make it
rather tricky to get this running on your system. Possibly we could ask
someone to sponsor a license for you as well...

Kris

Michael Tesch

2014-12-09 00:29:37 UTC

Hi, comments inline below....

On Mon, Dec 8, 2014 at 10:12 PM, Kris Thielemans <

Post by Kris Thielemans
From: William S Fulton, Sent: 08 December 2014 20:22

What is the problem here? Is there something different to all the other
languages?

I don't know travis-ci, so I have no idea what specifically is going wrong.

The issues are, separately:
1. running MATLAB requires an expensive license, many of us probably have
access to this through institutional licenses
2. there is no PPA for MATLAB (as far as I can tell, and the reason is
likely related to 1. BUT I'm not a Ubuntu user, so maybe there's a better
way that I dont know about...?)
3. travis-ci seems to be -only- a framework to run builds on their
Ubuntu/MacOS server farm... it's not clear if it's possible to run it
locally and separately from their farm, I could find a few blog posts about
how to do it, but it all seemed a little hacky and unsupported if that even
works, and it wasn't clear to me if their home-grown results would be
posted to the travis-ci website.
4. It may be possible to get a MATLAB license, and create a travis-ci
script to install and activate MATLAB on the testing instance, but I think
at the moment we're a long way from that at this point (cost of license, if
it would be within the license terms, travis-ci issues, etc...).

So, until we figure out the MATLAB issue, I'm proposing that what do is to
limit the travis-ci testing for swig-matlab to: create all the wrappers for
the test-suite, compile them, and link to a dummy library that emulates the
MATLAB interface.

Until we can run MATLAB on travis-ci, the actual test execution would have
to be done by people with MATLAB licenses.

The routes to getting matlab running under travis-ci are either:
- get travis-ci worker environment to run on a machine that has a MATLAB
license
- get a MATLAB license that we can run on travis-ci (directly from
Mathworks?), and figure out how to install MATLAB on travis-ci workers in
the 'before_install' phase (should be do-able, the matlab install script
can be run non-interactively)

Post by Kris Thielemans
If this testing is to work in Travis, MATLAB needs installing from

Post by William S Fulton
somewhere, most likely via a ppa? What did you have in mind?

Post by Michael Tesch
Would it be enough, as far as travis-ci is concerned, to simply
compile & link the wrapper files for the tests using the same flags
that MATLAB would?

Pkg-config etc have no idea about MATLAB.
I guess this will be a stupid question, as I haven't checked travis-ci, but
from your comment I suppose it runs completely independent from SWIG's
configure process? That would create complications as it'd be hard to
guarantee that the the travis-ci build will use the same options as the
configure (there could be 2 matlabs for instance). Possibly the configure
process could create the files necessary for travis-ci?
Currently, the test-suite in SWIG uses configure to find where MATLAB is,
and then compiles the wrappers with "mex", which is a script that comes with
MATLAB that calls the actual C++ compiler but with appropriate flags. Is
this not reusable?
Alternatively, you can find out (by running mex) what flags to use and then
just call the C++ compiler yourself. You might have seen the CMakeFiles.txt
stuff that I sent round which does this. It's quite tricky to do this in
general (depends on MATLAB version etc etc).

This is key -- end users will almost always compile the SWIG wrapper using
'mex' (actually just a shell script that sets some compile and link flags-
a poor man's make), but the mex compile flags are different for every
platform and version of matlab. The current SWIG configure.ac for matlab
looks for a matlab installation and uses that to compile the wrapper. I
started separating the wrapper generation from the matlab detection here:
(because actually you dont need matlab at all to generate a SWIG
wrapper...right?)

https://github.com/tesch1/swig/blob/d78648fa874ea7fdbd5197712464f4ccaa5ea4ec/configure.ac#L975
and where the mex build vars (MATLAB_*) are used:
https://github.com/tesch1/swig/blob/matlab-travis-ci/Examples/Makefile.in#L471

the idea is that you could do ./configure --with-matlab=R2011b-glnxa64
instead of --with-matlab=/usr/local/MATLAB/R2011b

It's not yet at the point of working, it still needs a dummy library to
link the wrapper against, but the basic idea is there -- when running
configure, the travis-ci test script can specify a "matlab version to
target" instead of detecting the currently installed matlab.

That branch also has the start of travis-ci support for matlab, but it
doesn't do anything because the compile (without mex.h) simply doesn't work:

https://travis-ci.org/tesch1/swig

Cheers,

Michael

Post by Kris Thielemans

William S Fulton

2014-12-11 20:40:24 UTC

Post by Michael Tesch
Hi, comments inline below....
On Mon, Dec 8, 2014 at 10:12 PM, Kris Thielemans
From: William S Fulton, Sent: 08 December 2014 20:22

Post by Michael Tesch
Hello,
I'm working on the matlab module, and am wondering what would

be the

Post by Michael Tesch
best way to provide the travis-ci testing support.
The problem is that there doesn't seem to be a reasonable way

to run

Post by Michael Tesch
MATLAB from within travis-ci.

What is the problem here? Is there something different to all

the other

Post by William S Fulton
languages?

I don't know travis-ci, so I have no idea what specifically is going wrong.
1. running MATLAB requires an expensive license, many of us probably
have access to this through institutional licenses
2. there is no PPA for MATLAB (as far as I can tell, and the reason is
likely related to 1. BUT I'm not a Ubuntu user, so maybe there's a
better way that I dont know about...?)
3. travis-ci seems to be -only- a framework to run builds on their
Ubuntu/MacOS server farm... it's not clear if it's possible to run it
locally and separately from their farm, I could find a few blog posts
about how to do it, but it all seemed a little hacky and unsupported
if that even works, and it wasn't clear to me if their home-grown
results would be posted to the travis-ci website.
4. It may be possible to get a MATLAB license, and create a travis-ci
script to install and activate MATLAB on the testing instance, but I
think at the moment we're a long way from that at this point (cost of
license, if it would be within the license terms, travis-ci issues,
etc...).

This is what I envisage and urge you to pursue. It is one license that
is installed on a cloud setup. Hopefully their licensing has moved into
the 21st century.

Post by Michael Tesch
So, until we figure out the MATLAB issue, I'm proposing that what do
is to limit the travis-ci testing for swig-matlab to: create all the
wrappers for the test-suite, compile them, and link to a dummy library
that emulates the MATLAB interface.

That sounds like a lot of work and doesn't guarantee very much wrt
running tests. Clearly it is better than nothing, but my opinion is it
would be better to spend time on getting a license for the SWIG project
instead. Also, wouldn't it be better to use gnumex? Surely that would
provide an api to compile against and you wouldn't have to reinvent what
gnumex already do? The tests might even run if gnumex is advanced enough
and will be easily installed on the Travis environment.

Post by Michael Tesch
Until we can run MATLAB on travis-ci, the actual test execution would
have to be done by people with MATLAB licenses.
- get travis-ci worker environment to run on a machine that has a
MATLAB license
- get a MATLAB license that we can run on travis-ci (directly from
Mathworks?), and figure out how to install MATLAB on travis-ci workers
in the 'before_install' phase (should be do-able, the matlab install
script can be run non-interactively)

Post by William S Fulton
If this testing is to work in Travis, MATLAB needs installing from
somewhere, most likely via a ppa? What did you have in mind?

I'm afraid this is impossible. MATLAB is commercial (and
expensive). I think
the only thing that could be done is to let travis-ci run the MATLAB tests
by those people who happen to have a MATLAB installation.

Post by Michael Tesch
Would it be enough, as far as travis-ci is concerned, to simply
compile & link the wrapper files for the tests using the same

flags

Post by Michael Tesch
that MATLAB would?

this is

Post by William S Fulton
done via pkg-config or similar tools such as python-config and
php-config during configure time. Anything else will lead to a messy
configure.ac <http://configure.ac> script which will need lots

of platform and compiler

Post by William S Fulton
specific code.

Pkg-config etc have no idea about MATLAB.
I guess this will be a stupid question, as I haven't checked travis-ci, but
from your comment I suppose it runs completely independent from SWIG's
configure process? That would create complications as it'd be hard to
guarantee that the the travis-ci build will use the same options as the
configure (there could be 2 matlabs for instance). Possibly the configure
process could create the files necessary for travis-ci?
Currently, the test-suite in SWIG uses configure to find where MATLAB is,
and then compiles the wrappers with "mex", which is a script that comes with
MATLAB that calls the actual C++ compiler but with appropriate flags. Is
this not reusable?
Alternatively, you can find out (by running mex) what flags to use and then
just call the C++ compiler yourself. You might have seen the CMakeFiles.txt
stuff that I sent round which does this. It's quite tricky to do this in
general (depends on MATLAB version etc etc).

So you are saying that you can use mex to obtain the flags for passing
to the compiler and linker? If so, the configure.ac should focus on
finding mex and then using it to extract the compile and link flags.
That is essentially all it needs to do. So sounds like you need to port
the CMake stuff to the autotools. Or even better, I just found
http://gnumex.sourceforge.net/autotools/. It already has the MATLAB
autoconf detection and sets the flags. I'd prefer we used and
contributed back to these m4 macros than maintain our own.

I really hope that mex is not anything like Scilab's builder. I'm
against using anything other than the SWIG build system for testing
given the experience over the years, so I doubt I'd be comfortable with
mex compiling the code.

Post by Michael Tesch
This is key -- end users will almost always compile the SWIG wrapper
using 'mex' (actually just a shell script that sets some compile and
link flags- a poor man's make), but the mex compile flags are
different for every platform and version of matlab. The current SWIG
configure.ac <http://configure.ac> for matlab looks for a matlab
installation and uses that to compile the wrapper. I started
(because actually you dont need matlab at all to generate a SWIG
wrapper...right?)

Correct, if you have to have MATLAB installed on the machine in order
for SWIG to generate everything required then there is something
fundamentally wrong. The output generated from SWIG must be independent
of OS and versions of everything else.

Post by Michael Tesch
https://github.com/tesch1/swig/blob/d78648fa874ea7fdbd5197712464f4ccaa5ea4ec/configure.ac#L975
https://github.com/tesch1/swig/blob/matlab-travis-ci/Examples/Makefile.in#L471
the idea is that you could do ./configure --with-matlab=R2011b-glnxa64
instead of --with-matlab=/usr/local/MATLAB/R2011b
It's not yet at the point of working, it still needs a dummy library
to link the wrapper against, but the basic idea is there -- when
running configure, the travis-ci test script can specify a "matlab
version to target" instead of detecting the currently installed matlab.
That branch also has the start of travis-ci support for matlab, but it
https://travis-ci.org/tesch1/swig

Independently of whether a MATLAB license is obtained for Travis, it is
essential that the normal './configure && make && make-check' works on a
machine with matlab installed. Without this I won't consider any merging
anything into master.

Post by Michael Tesch
Cheers,
Michael

Post by William S Fulton
I'd like to help you get this set up correctly sooner rather

than later.

Post by William S Fulton
Getting the build system correct is essential for me to consider

merging

Post by William S Fulton
into master. Once you have it working, I'll take a look for you.

Thanks for your offer. Unfortunately, the commercial nature seems to make it
rather tricky to get this running on your system. Possibly we could ask
someone to sponsor a license for you as well...

What I was thinking is if the MATLAB licensing can be sorted out to run
on Travis, then I'd be able to help as would any other member of the
SWIG community. If that is not possible, then there isn't much I can do
in this area as I don't really need nor want my own private Matlab license.

William

Joel Andersson

2014-12-11 21:14:01 UTC

Hi!

Just wanted to add that I have just requested a commercial MATLAB license
for myself (I'm self-employed) and that license is 2000 euros + VAT here in
Spain. While doing that, I also asked Mathworks about the possibility of
getting a MATLAB license for the SWIG development. They said that they
would get back to me about that. If I don't hear back, I could try again.
Maybe contacting the Mathworks USA directly.

Best regards,
Joel

Post by Michael Tesch
Hi, comments inline below....
On Mon, Dec 8, 2014 at 10:12 PM, Kris Thielemans <

Post by Kris Thielemans
From: William S Fulton, Sent: 08 December 2014 20:22

What is the problem here? Is there something different to all the other
languages?

I don't know travis-ci, so I have no idea what specifically is going wrong.

1. running MATLAB requires an expensive license, many of us probably
have access to this through institutional licenses
2. there is no PPA for MATLAB (as far as I can tell, and the reason is
likely related to 1. BUT I'm not a Ubuntu user, so maybe there's a better
way that I dont know about...?)
3. travis-ci seems to be -only- a framework to run builds on their
Ubuntu/MacOS server farm... it's not clear if it's possible to run it
locally and separately from their farm, I could find a few blog posts about
how to do it, but it all seemed a little hacky and unsupported if that even
works, and it wasn't clear to me if their home-grown results would be
posted to the travis-ci website.
4. It may be possible to get a MATLAB license, and create a travis-ci
script to install and activate MATLAB on the testing instance, but I think
at the moment we're a long way from that at this point (cost of license, if
it would be within the license terms, travis-ci issues, etc...).
This is what I envisage and urge you to pursue. It is one license that
is installed on a cloud setup. Hopefully their licensing has moved into the
21st century.
So, until we figure out the MATLAB issue, I'm proposing that what do is
to limit the travis-ci testing for swig-matlab to: create all the wrappers
for the test-suite, compile them, and link to a dummy library that emulates
the MATLAB interface.
That sounds like a lot of work and doesn't guarantee very much wrt
running tests. Clearly it is better than nothing, but my opinion is it
would be better to spend time on getting a license for the SWIG project
instead. Also, wouldn't it be better to use gnumex? Surely that would
provide an api to compile against and you wouldn't have to reinvent what
gnumex already do? The tests might even run if gnumex is advanced enough
and will be easily installed on the Travis environment.
Until we can run MATLAB on travis-ci, the actual test execution would
have to be done by people with MATLAB licenses.
- get travis-ci worker environment to run on a machine that has a MATLAB
license
- get a MATLAB license that we can run on travis-ci (directly from
Mathworks?), and figure out how to install MATLAB on travis-ci workers in
the 'before_install' phase (should be do-able, the matlab install script
can be run non-interactively)

Post by Kris Thielemans
If this testing is to work in Travis, MATLAB needs installing from

Post by William S Fulton
somewhere, most likely via a ppa? What did you have in mind?

Post by Michael Tesch
Would it be enough, as far as travis-ci is concerned, to simply
compile & link the wrapper files for the tests using the same flags
that MATLAB would?

Pkg-config etc have no idea about MATLAB.
I guess this will be a stupid question, as I haven't checked travis-ci, but
from your comment I suppose it runs completely independent from SWIG's
configure process? That would create complications as it'd be hard to
guarantee that the the travis-ci build will use the same options as the
configure (there could be 2 matlabs for instance). Possibly the configure
process could create the files necessary for travis-ci?
Currently, the test-suite in SWIG uses configure to find where MATLAB is,
and then compiles the wrappers with "mex", which is a script that comes with
MATLAB that calls the actual C++ compiler but with appropriate flags. Is
this not reusable?
Alternatively, you can find out (by running mex) what flags to use and then
just call the C++ compiler yourself. You might have seen the
CMakeFiles.txt
stuff that I sent round which does this. It's quite tricky to do this in
general (depends on MATLAB version etc etc).
So you are saying that you can use mex to obtain the flags for

passing to the compiler and linker? If so, the configure.ac should focus
on finding mex and then using it to extract the compile and link flags.
That is essentially all it needs to do. So sounds like you need to port the
CMake stuff to the autotools. Or even better, I just found
http://gnumex.sourceforge.net/autotools/. It already has the MATLAB
autoconf detection and sets the flags. I'd prefer we used and contributed
back to these m4 macros than maintain our own.
I really hope that mex is not anything like Scilab's builder. I'm against
using anything other than the SWIG build system for testing given the
experience over the years, so I doubt I'd be comfortable with mex compiling
the code.
This is key -- end users will almost always compile the SWIG wrapper
using 'mex' (actually just a shell script that sets some compile and link
flags- a poor man's make), but the mex compile flags are different for
every platform and version of matlab. The current SWIG configure.ac for
matlab looks for a matlab installation and uses that to compile the
wrapper. I started separating the wrapper generation from the matlab
detection here: (because actually you dont need matlab at all to generate a
SWIG wrapper...right?)
Correct, if you have to have MATLAB installed on the machine in order for
SWIG to generate everything required then there is something fundamentally
wrong. The output generated from SWIG must be independent of OS and
versions of everything else.
https://github.com/tesch1/swig/blob/d78648fa874ea7fdbd5197712464f4ccaa5ea4ec/configure.ac#L975
https://github.com/tesch1/swig/blob/matlab-travis-ci/Examples/Makefile.in#L471
the idea is that you could do ./configure --with-matlab=R2011b-glnxa64
instead of --with-matlab=/usr/local/MATLAB/R2011b
It's not yet at the point of working, it still needs a dummy library to
link the wrapper against, but the basic idea is there -- when running
configure, the travis-ci test script can specify a "matlab version to
target" instead of detecting the currently installed matlab.
That branch also has the start of travis-ci support for matlab, but it
https://travis-ci.org/tesch1/swig
Independently of whether a MATLAB license is obtained for Travis, it
is essential that the normal './configure && make && make-check' works on a
machine with matlab installed. Without this I won't consider any merging
anything into master.
Cheers,
Michael

Post by Kris Thielemans

run on Travis, then I'd be able to help as would any other member of the
SWIG community. If that is not possible, then there isn't much I can do in
this area as I don't really need nor want my own private Matlab license.
William
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Swig-devel mailing list
https://lists.sourceforge.net/lists/listinfo/swig-devel

--
--
Joel Andersson, PhD
Ptge. Busquets 11-13, atico 3
E-08940 Cornella de Llobregat, Spain
Home: +34-93-6034011
Mobile: +32-486-672874 (Belgium) / +34-63-4408800 (Spain) / +46-707-360512
(Sweden)

Michael Tesch

2014-12-11 21:13:42 UTC

4. It may be possible to get a MATLAB license, and create a travis-ci
script to install and activate MATLAB on the testing instance, but I think
at the moment we're a long way from that at this point (cost of license, if
it would be within the license terms, travis-ci issues, etc...).

This is what I envisage and urge you to pursue. It is one license that

Post by Michael Tesch
is installed on a cloud setup. Hopefully their licensing has moved into the
21st c

You're right, we should at the very least ask MathWorks if they'd be
willing to help us out on this. SWIG for Matlab seems like it would be a
big win for their customers.

@Kris & @Joel & other matlab developers -- does someone want to take point
on this? I'd be willing to give it a shot if nobody's interested...?
draft up a first contact email for review, start asking around for sales
contacts... etc.. thoughts? Any other ideas of how to approach this?

Post by Michael Tesch
entury.
So, until we figure out the MATLAB issue, I'm proposing that what do is
to limit the travis-ci testing for swig-matlab to: create all the wrappers
for the test-suite, compile them, and link to a dummy library that emulates
the MATLAB interface.
That sounds like a lot of work and doesn't guarantee very much wrt
running tests. Clearly it is better than nothing, but my opinion is it
would be better to spend time on getting a license for the SWIG project
instead. Also, wouldn't it be better to use gnumex? Surely that would
provide an api to compile against and you wouldn't have to reinvent what
gnumex already do? The tests might even run if gnumex is advanced enough
and will be easily installed on the Travis environment.

Wasn't that much work -- got it running last night:
https://travis-ci.org/tesch1/swig (see build 6.4 -- the output is a little
bit too verbose at the moment, but it does compile and link the swig
wrapper for each of the tests... the ones that currently compile and link
at least...)

https://github.com/tesch1/swig/tree/matlab-travis-ci

Post by Michael Tesch
Alternatively, you can find out (by running mex) what flags to use and then

Post by Kris Thielemans
just call the C++ compiler yourself. You might have seen the
CMakeFiles.txt
stuff that I sent round which does this. It's quite tricky to do this in
general (depends on MATLAB version etc etc).
So you are saying that you can use mex to obtain the flags for

Yes, if you run mex with -v it dumps out all the flags it uses to build
matlab extensions, and those can be used by another build system to build
the extensions outside of the mex script. My changes (linked above in my
matlab-travis-ci support branch) to the configure script extract the build
flags from mex this way when building normally ("normally" == not for
travis-ci).

Post by Michael Tesch
I really hope that mex is not anything like Scilab's builder. I'm against
using anything other than the SWIG build system for testing given the
experience over the years, so I doubt I'd be comfortable with mex compiling
the code.
This is key -- end users will almost always compile the SWIG wrapper
using 'mex' (actually just a shell script that sets some compile and link
flags- a poor man's make), but the mex compile flags are different for
every platform and version of matlab. The current SWIG configure.ac for
matlab looks for a matlab installation and uses that to compile the
wrapper. I started separating the wrapper generation from the matlab
detection here: (because actually you dont need matlab at all to generate a
SWIG wrapper...right?)
Correct, if you have to have MATLAB installed on the machine in order for
SWIG to generate everything required then there is something fundamentally
wrong. The output generated from SWIG must be independent of OS and
versions of everything else.
https://github.com/tesch1/swig/blob/d78648fa874ea7fdbd5197712464f4ccaa5ea4ec/configure.ac#L975
https://github.com/tesch1/swig/blob/matlab-travis-ci/Examples/Makefile.in#L471
the idea is that you could do ./configure --with-matlab=R2011b-glnxa64
instead of --with-matlab=/usr/local/MATLAB/R2011b
It's not yet at the point of working, it still needs a dummy library to
link the wrapper against, but the basic idea is there -- when running
configure, the travis-ci test script can specify a "matlab version to
target" instead of detecting the currently installed matlab.
That branch also has the start of travis-ci support for matlab, but it
https://travis-ci.org/tesch1/swig
Independently of whether a MATLAB license is obtained for Travis, it
is essential that the normal './configure && make && make-check' works on a
machine with matlab installed. Without this I won't consider any merging
anything into master.

Check. The interim mex stubs and changes to the configure script will let
you configure and build with matlab as a target without having matlab
installed, it just wont be possible to run any tests without it. Currently
the default is to try to detect matlab, and if nothing is detected, not to
build matlab support, UNLESS a --with-matlab= was given with a recognized
version and operating system, which then selects the known mex build flags
for that os/version combo.

Thanks for your offer. Unfortunately, the commercial nature seems to make it

Post by Kris Thielemans
rather tricky to get this running on your system. Possibly we could ask
someone to sponsor a license for you as well...
What I was thinking is if the MATLAB licensing can be sorted out to

We should just ask someone at MathWorks and see what they say -- maybe
start with a sales contact or apps engineer?

Cheers,

Michael

Kris Thielemans

2014-12-11 22:24:46 UTC

Hi

This email thread is getting a bit out of hand (and part HTML), so I cut everything that’s not relevant to my answer.

WF> So you are saying that you can use mex to obtain the flags for passing to the
WF> compiler and linker? <snip> Or even better, I just found
WF> http://gnumex.sourceforge.net/autotools/. It already has the MATLAB
WF> autoconf detection and sets the flags. I'd prefer we used and contributed
WF> back to these m4 macros than maintain our own.

Not a bad idea but I note that Gnumex is for windows. I don't know if the autotools there are windows specific or not (I couldn't find the source for the autotools).

WF> I really hope that mex is not anything like Scilab's builder. I'm against
WF> using anything other than the SWIG build system for testing given the
WF> experience over the years, so I doubt I'd be comfortable with mex compiling the code.

I think there might be a misunderstanding here. Running swig does not need matlab at all, nor does it need mex. What the test-suite was doing before Michael made changes on his branch (which I haven't checked) is to use mex to compile the tests (and matlab to run them). So, configure.ac just finds mex and matlab.

I see no particular harm in this for SWIG. (Yes, this "use mex" strategy doesn't work for a serious matlab-swigged project, but that shouldn't be the concern of SWIG).

Personally, I'd vote for using the mex script supplied by matlab for the SWIG tests. It's guaranteed to keep working. (Finding flags from "mex -v" has to be tweaked for different matlab versions, as the MathWorks doesn't care about people using fancy build tools).

MT> The current SWIG configure.ac for matlab looks for a matlab installation and
MT> uses that to compile the wrapper. I started separating the wrapper generation
MT> from the matlab detection here

I'm not sure why this needed separation. The swig executable itself is independent of which tools configure finds. Even the install part always installs everything as far as I know. The only place where a difference is made is in the makefile for the examples and the test-suite. As far as I know, this is true for python etc as well.

MT> the idea is that you could do ./configure --with-matlab=R2011b-glnxa64 instead of
MT> --with-matlab=/usr/local/MATLAB/R2011b

The aim of these changes was to be able to run "generation+compilation" tests without matlab. But why would you need to target a specific matlab version for this? Your "fake" mex.h and library will not depend on the version. And if you do have different matlab versions, you still have to specify the location of the one you want to use.

I'd prefer the alternative solution to let the tester say

make --with-matlab=/home/tester/swig/matlabstubs

that seems simpler to me.

A final comment. The alternative to using travis-ci is to move the CMake and CTest. That allows anyone to submit a test-result to a dashboard, so you would be able to have someone with a matlab license submit the matlab-tests to the dashboard (and it would allow building/testing on Windows). But that'd of course be quite a lot of work.

Kris

Michael Tesch

2014-12-11 23:23:35 UTC

On Thu, Dec 11, 2014 at 11:24 PM, Kris Thielemans <

Post by Kris Thielemans
Hi
This email thread is getting a bit out of hand (and part HTML), so I cut

everything thatâs not relevant to my answer.

Post by Kris Thielemans
WF> So you are saying that you can use mex to obtain the flags for passing to the
WF> compiler and linker? <snip> Or even better, I just found
WF> http://gnumex.sourceforge.net/autotools/. It already has the MATLAB
WF> autoconf detection and sets the flags. I'd prefer we used and contributed
WF> back to these m4 macros than maintain our own.
Not a bad idea but I note that Gnumex is for windows. I don't know if the

autotools there are windows specific or not (I couldn't find the source for
the autotools).

need matlab at all, nor does it need mex. What the test-suite was doing
before Michael made changes on his branch (which I haven't checked) is to
use mex to compile the tests (and matlab to run them). So, configure.ac
just finds mex and matlab.
Have a look, it's all on github. The old configure.ac enables/disables
matlab support only based on whether the binaries for mex and matlab are
found.

Travis-ci looks pretty useful, for example you can configure it to
automatically build incoming pull-requests, so at least when you start
thinking about merging there's a datapoint as to whether something even
compiles.

The goal of my changes were to provide a way to test compilation of the
swig wrapper for matlab without having matlab, for any known set of mex
build flags -- as pointed out, these flags may change from version to
version and os to os, and a swig developer may want to know if some changes
are going to break the build for versions of matlab s/he doesn't have
access to.

Is putting all that in the configure script the right way to handle this?
I'm not sure, but it was the easiest way to get it going for now, in as
similar way as possible to the other swig targets.

I also like the idea of having a "fake" mex and matlab in, say,
swig/Examples/test-suite/matlab/testharness that could provide the same
functionality.

Post by Kris Thielemans
I see no particular harm in this for SWIG. (Yes, this "use mex" strategy

doesn't work for a serious matlab-swigged project, but that shouldn't be
the concern of SWIG).

Post by Kris Thielemans
Personally, I'd vote for using the mex script supplied by matlab for the

SWIG tests. It's guaranteed to keep working. (Finding flags from "mex -v"
has to be tweaked for different matlab versions, as the MathWorks doesn't
care about people using fancy build tools).

Post by Kris Thielemans
MT> The current SWIG configure.ac for matlab looks for a matlab installation and
MT> uses that to compile the wrapper. I started separating the wrapper generation
MT> from the matlab detection here
I'm not sure why this needed separation. The swig executable itself is

independent of which tools configure finds. Even the install part always
installs everything as far as I know. The only place where a difference is
made is in the makefile for the examples and the test-suite. As far as I
know, this is true for python etc as well.
So that if you dont have matlab you can still build and -partially- test
the swig matlab wrappers. The configure script also sets up the testing
environment. This is a stop-gap until there's an automated solution for
running against an actual matlab install, and a "better-than-nothing" for
developers who are never going to have a matlab install.

Post by Kris Thielemans
MT> the idea is that you could do ./configure

--with-matlab=R2011b-glnxa64 instead of

Post by Kris Thielemans
MT> --with-matlab=/usr/local/MATLAB/R2011b
The aim of these changes was to be able to run "generation+compilation"

tests without matlab. But why would you need to target a specific matlab
version for this? Your "fake" mex.h and library will not depend on the
version. And if you do have different matlab versions, you still have to
specify the location of the one you want to use.
Because different versions of matlab/mex may have different build flags,
and you to have the build flags for the current "stop-gap" to match the
system you're running on (mac/windows/linux).

Post by Kris Thielemans
I'd prefer the alternative solution to let the tester say
make --with-matlab=/home/tester/swig/matlabstubs
that seems simpler to me.

What would it do differently in comparison to my solution? It just seems
like a trade-off between complexity in configure.ac and complexity in some
matlab/mex emulation scripts... and additionally needs a separate mechanism
to select compile flags appropriate for the os, etc...

Post by Kris Thielemans
A final comment. The alternative to using travis-ci is to move the CMake

and CTest. That allows anyone to submit a test-result to a dashboard, so
you would be able to have someone with a matlab license submit the
matlab-tests to the dashboard (and it would allow building/testing on
Windows). But that'd of course be quite a lot of work.

Post by Kris Thielemans
Kris

Free software.... someone has to do all the work :o)

Cheers

Michael

William S Fulton

2014-12-12 18:57:41 UTC

Post by Michael Tesch
On Thu, Dec 11, 2014 at 11:24 PM, Kris Thielemans

Post by Kris Thielemans
Not a bad idea but I note that Gnumex is for windows. I don't know

if the autotools there are windows specific or not (I couldn't find
the source for the autotools).

The example.zipi download on http://gnumex.sourceforge.net/autotools/
has the m4 code.

Post by Kris Thielemans
WF> I really hope that mex is not anything like Scilab's builder.

I'm against

Post by Kris Thielemans
WF> using anything other than the SWIG build system for testing

given the

Post by Kris Thielemans
WF> experience over the years, so I doubt I'd be comfortable with

mex compiling the code.

Post by Kris Thielemans
I think there might be a misunderstanding here. Running swig does

not need matlab at all, nor does it need mex. What the test-suite was
doing before Michael made changes on his branch (which I haven't
checked) is to use mex to compile the tests (and matlab to run them).
So, configure.ac <http://configure.ac> just finds mex and matlab.
Have a look, it's all on github. The old configure.ac
<http://configure.ac> enables/disables matlab support only based on
whether the binaries for mex and matlab are found.

I don't see where MATLAB_MEX is actually used if mex is found. All I can
see is MATLAB_CC and MATLAB_CXX set to gcc, which is what the other
languages do and that is all fine.

Post by Michael Tesch
I also like the idea of having a "fake" mex and matlab in, say,
swig/Examples/test-suite/matlab/testharness that could provide the
same functionality.

If we have to have this, Tools/matlab would be better, it'll need to
work for the Examples/matlab examples too.

Post by Kris Thielemans
I see no particular harm in this for SWIG. (Yes, this "use mex"

strategy doesn't work for a serious matlab-swigged project, but that
shouldn't be the concern of SWIG).

Post by Kris Thielemans
Personally, I'd vote for using the mex script supplied by matlab for

the SWIG tests. It's guaranteed to keep working. (Finding flags from
"mex -v" has to be tweaked for different matlab versions, as the
MathWorks doesn't care about people using fancy build tools).

I would do timing tests to see what the performance impact of mex is.
For Scilab it was a joke how much the equivalent tool added in overhead
and complexity to the SWIG testing.

Post by Michael Tesch
So that if you dont have matlab you can still build and -partially-
test the swig matlab wrappers.

Also, please make sure 'make partialcheck-matlab-test-suite' works as
running diff over the output is an efficient way to look for regressions
when changes are made in the core part of SWIG.

William

Kris Thielemans

2014-12-13 11:38:30 UTC

From: William Fulton Sent: 12 December 2014 18:58

On 11/12/14 23:23, Michael Tesch wrote:

On Thu, Dec 11, 2014 at 11:24 PM, Kris Thielemans <***@gmail.com <mailto:***@gmail.com> > wrote:

I don't see where MATLAB_MEX is actually used if mex is found. All I can see is MATLAB_CC and MATLAB_CXX set to gcc, which is what the other languages do and that is all fine.

Exactly, MATLAB_MEX is (in my fork) only used in Examples/Makefile.in, i.e. for the build instructions of the wrappers. Once again, for building/installing SWIG there is no dependency (in my fork) on an existing MATLAB installation. The resulting build will still be able to wrap to matlab. You can check that for instance by configuring with ââwithout-matlabâ.

I also like the idea of having a "fake" mex and matlab in, say, swig/Examples/test-suite/matlab/testharness that could provide the same functionality.

If we have to have this, Tools/matlab would be better, it'll need to work for the Examples/matlab examples too.

Any place is fine for me of course.

Post by Kris Thielemans
I see no particular harm in this for SWIG. (Yes, this "use mex" strategy doesn't work for a serious matlab-swigged project, but that shouldn't be the concern of SWIG).
Personally, I'd vote for using the mex script supplied by matlab for the SWIG tests. It's guaranteed to keep working. (Finding flags from "mex -v" has to be tweaked for different matlab versions, as the MathWorks doesn't care about people using fancy build tools).

I would do timing tests to see what the performance impact of mex is. For Scilab it was a joke how much the equivalent tool added in overhead and complexity to the SWIG testing.

The mex script from MathWorks is quite simple. It is just settings flags and calling the compiler (which the user will have to have selected first with âmex âsetupâ). Overhead is essentially zero.

Also, please make sure 'make partialcheck-matlab-test-suite' works as running diff over the output is an efficient way to look for regressions when changes are made in the core part of SWIG

That is easy: in Examples/Makefile.in, prepend $(COMPILETOOL) before calls to $(MATLAB_MEX) (this should have been there I guess). Iâll commit this later on my fork, but I guess I need to merge Joelâs first.

(By the way, matlab-partialcheck then currently only fails template_default2 and template_specialization_defarg because of some Octave remnants).

Kris

William S Fulton

2015-05-10 14:38:20 UTC

Post by Michael Tesch
On Thu, Dec 11, 2014 at 11:24 PM, Kris Thielemans

Post by Kris Thielemans
Not a bad idea but I note that Gnumex is for windows. I don't know if the
autotools there are windows specific or not (I couldn't find the source for
the autotools).

The example.zipi download on http://gnumex.sourceforge.net/autotools/ has
the m4 code.

Post by Kris Thielemans
WF> I really hope that mex is not anything like Scilab's builder. I'm against
WF> using anything other than the SWIG build system for testing given the
WF> experience over the years, so I doubt I'd be comfortable with mex compiling the code.
I think there might be a misunderstanding here. Running swig does not need
matlab at all, nor does it need mex. What the test-suite was doing before
Michael made changes on his branch (which I haven't checked) is to use mex
to compile the tests (and matlab to run them). So, configure.ac just finds
mex and matlab.

Have a look, it's all on github. The old configure.ac enables/disables
matlab support only based on whether the binaries for mex and matlab are
found.
I don't see where MATLAB_MEX is actually used if mex is found. All I can see
is MATLAB_CC and MATLAB_CXX set to gcc, which is what the other languages do
and that is all fine.
I also like the idea of having a "fake" mex and matlab in, say,
swig/Examples/test-suite/matlab/testharness that could provide the same
functionality.
If we have to have this, Tools/matlab would be better, it'll need to work
for the Examples/matlab examples too.

Post by Kris Thielemans
I see no particular harm in this for SWIG. (Yes, this "use mex" strategy
doesn't work for a serious matlab-swigged project, but that shouldn't be the
concern of SWIG).
Personally, I'd vote for using the mex script supplied by matlab for the
SWIG tests. It's guaranteed to keep working. (Finding flags from "mex -v"
has to be tweaked for different matlab versions, as the MathWorks doesn't
care about people using fancy build tools).

I would do timing tests to see what the performance impact of mex is. For
Scilab it was a joke how much the equivalent tool added in overhead and
complexity to the SWIG testing.
So that if you dont have matlab you can still build and -partially- test the
swig matlab wrappers.
Also, please make sure 'make partialcheck-matlab-test-suite' works as
running diff over the output is an efficient way to look for regressions
when changes are made in the core part of SWIG.

I was just wondering what the status of this Matlab module and the
testing of it is? Is there any plan to get it ready for adding to the
main SWIG code base?

William

Joel Andersson

2015-06-02 09:29:25 UTC

Hi William, all,

Sorry for late answer, saw this mail only now. There has not been any major
news from my side the last couple of months. I plan to continue to work on
this shortly, but I'm still held up by other things. Finishing the Matlab
module is certainly on the critical path for me and the projects I'm
involved in.

Joel

Post by Michael Tesch
On Thu, Dec 11, 2014 at 11:24 PM, Kris Thielemans

Post by Kris Thielemans
Not a bad idea but I note that Gnumex is for windows. I don't know if

the

Post by Kris Thielemans
autotools there are windows specific or not (I couldn't find the source

for

Post by Kris Thielemans
the autotools).

The example.zipi download on http://gnumex.sourceforge.net/autotools/

has

Post by Michael Tesch
the m4 code.

Post by Kris Thielemans
WF> I really hope that mex is not anything like Scilab's builder. I'm against
WF> using anything other than the SWIG build system for testing given

the

Post by Kris Thielemans
WF> experience over the years, so I doubt I'd be comfortable with mex
compiling the code.
I think there might be a misunderstanding here. Running swig does not

need

Post by Kris Thielemans
matlab at all, nor does it need mex. What the test-suite was doing

before

Post by Kris Thielemans
Michael made changes on his branch (which I haven't checked) is to use

mex

Post by Kris Thielemans
to compile the tests (and matlab to run them). So, configure.ac just

finds

Post by Kris Thielemans
mex and matlab.

see

Post by Michael Tesch
is MATLAB_CC and MATLAB_CXX set to gcc, which is what the other

languages do

Post by Michael Tesch
and that is all fine.
I also like the idea of having a "fake" mex and matlab in, say,
swig/Examples/test-suite/matlab/testharness that could provide the same
functionality.
If we have to have this, Tools/matlab would be better, it'll need to work
for the Examples/matlab examples too.

Post by Kris Thielemans
I see no particular harm in this for SWIG. (Yes, this "use mex" strategy
doesn't work for a serious matlab-swigged project, but that shouldn't

be the

Post by Kris Thielemans
concern of SWIG).
Personally, I'd vote for using the mex script supplied by matlab for the
SWIG tests. It's guaranteed to keep working. (Finding flags from "mex

-v"

Post by Kris Thielemans
has to be tweaked for different matlab versions, as the MathWorks

doesn't

Post by Kris Thielemans
care about people using fancy build tools).

the

Post by Michael Tesch
swig matlab wrappers.
Also, please make sure 'make partialcheck-matlab-test-suite' works as
running diff over the output is an efficient way to look for regressions
when changes are made in the core part of SWIG.

I was just wondering what the status of this Matlab module and the
testing of it is? Is there any plan to get it ready for adding to the
main SWIG code base?
William
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Swig-devel mailing list
https://lists.sourceforge.net/lists/listinfo/swig-devel

William S Fulton

2014-12-12 19:23:32 UTC

Post by Michael Tesch
On Thu, Dec 11, 2014 at 11:24 PM, Kris Thielemans

Post by Kris Thielemans
A final comment. The alternative to using travis-ci is to move the

CMake and CTest. That allows anyone to submit a test-result to a
dashboard, so you would be able to have someone with a matlab license
submit the matlab-tests to the dashboard (and it would allow
building/testing on Windows). But that'd of course be quite a lot of work.

Post by Kris Thielemans
Kris

Free software.... someone has to do all the work :o)

CMake and CTest have been discussed before, take a look at the emails in
this chain http://article.gmane.org/gmane.comp.programming.swig.devel/21611.

William

Kris Thielemans

2014-12-13 09:52:57 UTC