On Thu, Jul 29, 2010 at 9:14 PM, Steven G. Johnson <[email protected]>wrote:

> Thanks for looking into this, Benoit!  Does this build a static library
> (.lib) or a shared library (.dll), or both?
>
>
Thanks! that's true currently it is only for a static library. It could be
good to also have the option to compile
as a shared library with CMake, i will do that.




> On Jul 29, 2010, at 8:27 PM, Be-noix wrote:
>
>> - rename #include "config.h" to #include "config_nlopt.h"
>> because my project already had a config.h (bad idea)
>>
>
> This doesn't make sense to me.  Surely you are compiling NLopt as a
> library?  In which case the config.h file is internal to NLopt and is
> irrelevant to programs using NLopt.  Programs using NLopt need only include
> the nlopt.h header and link the NLopt library.
>


That's true that for the nlopt library itself there is no problem.
But in my project i was including both api/nlopt.h and util/nlopt-util.h (to
use the function nlopt_seconds)
This nlopt-util.h file includes config.h, and there were some conflicts.



>  because VC was in 'C' mode, and not 'C++', and you can define a
>> variable only at the beginning of a block in C
>>
>
> Actually, mixed declarations and code have been been a standard part of C
> for 11 years now.  But I generally try to stick with 1989 C anyway, and I
> will fix the two instances you spotted in the next NLopt release.
>
> (With these two fixes, it now compiles with gcc -std=c89 -pedantic.)
>
>  (I tried for one hour to force VC to use C++ but without any success)
>>
>
> If NLopt is not compiling as C++, I'd be interested to hear what the
> problems are.  I can compile with "g++ -pedantic -ansi" without problems.
>


No no it's definitely compiling as C++, what i said was not clear. The thing
is that in VS (if i don't make a mistake)
all files with .c are compiled as C, and cxx/cpp as C++. By renaming
optimize.c to optimize.cxx there is no more
'block' error. Another option: in the VS interface i could select the file
optimize.c and manually set the flag /TP to force its
compilation in C++ and there wouldn't be the 'block' error. I tried to set
that flag /TP in the CMakeLists.txt
but it didn't worked.

That's strange because VS is generally really less stringent than gcc about
the norms, and so here it seems it sticks
as you said to the 1989 C and not gcc.


>
>  And success!
>> Maybe Steven you could include these modifs in the original source code?
>> (and if you want to CMakeList.txt ?)
>>
>
> I'd be happy to post the CMakeList.txt on the web site, although I'd prefer
> not to change the name of the config.h header file as explained above.
>

sure. But what do you think about my problem with nlopt-util? Is the include
of config.h really necessary in that
file?


>  Steven
>
> PS. I notice that the C99/IEEE function copysign is missing on Windows so
> you defined a macro, although apparently Microsoft defined a _copysign
> function because they love to be different.  I'll include a check for this
> in the next release.
>

yes that's true. In fact i did have a linker warning about _copysign (but
not a compiler warning, so VS knew
what was that function). And i didn't tried to look in which lib
in _copysign , i just made the macro.

Benoit

-- 
/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /
/ /
Benoit Scherrer
Postdoctoral Research Fellow
Computational Radiology Laboratory,
Harvard Medical School (Boston)

http://www.crl.med.harvard.edu/
http://www.BenoitScherrer.com
/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /
/ /
_______________________________________________
NLopt-discuss mailing list
[email protected]
http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/nlopt-discuss

Reply via email to