Re: GSOC second part

[Piotr Held]

2015-07-06 17:09 GMT-06:00 John W. Eaton <address@hidden>:

On 07/06/2015 06:22 PM, Carnë Draug wrote:

On 6 July 2015 at 22:13, Piotr Held <address@hidden> wrote:

[...]
I have published on the repo version 0.2.0. Should I try to get it to Octave
Forge? I am not sure if it's ready.

First of all, I use lambdas for one function, so I needed to add -std=c++11
to my CFLAGS (which I probably could rename CXXFLAGS). I don't have any
autoconf scripts to check if the compiler someone uses actually can compile
code using that flag. Do you have any ideas on this?
[...]

The image package also makes use of lambdas and requires that flag.  Take
a look at how it does it.

http://hg.code.sf.net/p/octave/image/file/e977104b2492/src/configure.ac

http://hg.code.sf.net/p/octave/image/file/e977104b2492/src/m4/ax_cxx_compile_stdcxx_11.m4

http://hg.code.sf.net/p/octave/image/file/e977104b2492/src/Makefile.in

Carnë

Modifying user variables like CPPFLAGS, CFLAGS, or CXXFLAGS in configure scripts is generally discouraged:


https://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html

Also, what will happen if -std=c++11 is not supported?  Does building the entire package fail, or is a feature disabled?  If possible, please make the lack of specific compiler features as harmless as possible.

Thanks,

jwe

Thanks for your ides and suggestions. I am working on implementing them.

I have a question: how do I generate a tarball of the package that compiles properly if the the repo doesn't log changes to src/configure (only to src/configure.ac)?

And also how can I test if the generated configure script works properly? Should I compile my version of g++ so that it does not support '-std=gnu++11' and then run the configure script using this new version of g++ or is there some smarter way to do this?

My progress so far: https://bitbucket.org/josiah425/tisean/src/e721c6d4feb0e12f97b58fc141864da56d399236/src/?at=devel

Piotr