Re: [Help-gsl] CMake build support for GSL

[Nagy-Egri Máté Ferenc]

Hi!


Thank you for the update. I figured that the bulk of CMake-izing GSL would be 
the __declspec(dllexport) part, as it is the biggest pain when porting linux 
libraries over to Windows. There is a VS solution available at 
http://gladman.plushost.co.uk/oldsite/computing/gsl-1.16-vc11.zip (although the 
server seems to be down now) that does the entire work with 2 special VS 
projects inside the solution. One modified the header files in order to get the 
declspec entries (not recommended), the other one generates a longer .def file 
that holds function declspec entried too(recommended).


If you would port the gsldef project inside the solution to Cmake, I’d know 
where my first Christmas greetings card would go. 😊


Off-topic: Where would be the place to propose heretic ideas such as making 
more GNU projects Windows friendly out-of-the-box? GNU MPFR would be another 
welcome library on the dark side of computing, just to name one of many 
projects.


Cheers,

Máté






Feladó: address@hidden
Elküldve: ‎csütörtök‎, ‎2014‎. ‎május‎ ‎8‎. ‎19‎:‎30
Címzett: Máté Ferenc Nagy-Egri
Másolat: address@hidden





Sorry, I thought you were talking about build configuration directories, not 
the install directories. I've added an option GSL_INSTALL_MULTI_CONFIG here: 
https://github.com/ampl/gsl/commit/0cf47581583de7ed4ee1cf0a095066af0d2f97d1. 
When turned ON, this option tells CMake to install libraries under 
${CMAKE_INSTALL_PREFIX}/${CONFIG}. It is OFF by default to follow standard 
conventions.




As for dynamic (shared) libraries, on Linux and Mac it is as simple as adding 
SHARED to add_library:




  add_library(gsl SHARED ${GSL_SOURCES})




On Windows, it is not that simple, because exported symbols should either be 
declared with __declspec(dllexport) or exported via a .def file. As far as I 
can see, GSL only declares variables, but not functions, with 
__declspec(dllexport) if GSL_DLL and DLL_EXPORT are defined. And I don't see 
any .def files either.





Best regards,

Victor


On Wed, May 7, 2014 at 1:40 AM, Nagy-Egri Máté Ferenc <address@hidden> wrote:




The error might be on my side, but this is not what I experience. I create 
VS2013 Project, and even though the CMAKE_INSTALL_PREFIX is set to 
C:\Kellekek\GSL I have the libs installed under C:\Kellekek\GSL\lib for all 
configurations. Since GSL is not a library that canonically has different names 
for the different configurations, I always have to create the Release and Debug 
directories by hand in the install location and copy the libs over.




I fetched the CMake file just 2 days ago, it’s not outdated.




What is the way of specifying whether I want a dynamic library or a static one? 
It seems that the CMake file assumes I want a static lib, but infact I prefer 
dll-s. The option does not come up when configuring with cmake-gui.exe




Any insights as to what I’m doing wrong?






Feladó: address@hidden
Elküldve: ‎kedd‎, ‎2014‎. ‎május‎ ‎6‎. ‎19‎:‎01
Címzett: Máté Ferenc Nagy-Egri
Másolat: address@hidden







Hi Máté,



I'm glad you liked it.




As for multi-configuration builds, they are already supported. When using a 
multi-configuration generator such as MSVC, release binaries are placed in the 
Release directory and debug ones are placed in the Debug directory. You can 
also have separate out-of-tree builds with different settings for 
single-configuration CMake generators such as Makefile generator.




Best regards,

Victor







On Tue, May 6, 2014 at 12:41 AM, Nagy-Egri Máté Ferenc <address@hidden> wrote:

Hi!


I have recently posted how nice it would be if NuGet or Chocolatey would get 
some GNU loving, and GSL could be the first one. The CMake file you created 
does show a lot of and great congrats. I managed to build the libraries just 
fine, I would have just one comment:


It would be nice if the CMakeLists.txt file supported multi-configuration 
builds without seperate install prefixes. For eg. if on Windows, where building 
under lib/Debug and lib/Release is very common, it would be nice if I wouldn’t 
have to always build and create the directory structure myself, but have the 
makefile do it for me.



Other than this, fantastic work!


Máté





Feladó: Patrick Alken
Elküldve: ‎kedd‎, ‎2014‎. ‎április‎ ‎29‎. ‎22‎:‎36
Címzett: address@hidden







Hi Victor,

   Thanks it looks like you did a lot of work on this. I was able to
build the current git repository easily with your script. I've added the
file in contrib/CMakeLists.txt so others can use it if they want.

Thanks,
Patrick

On 04/29/2014 02:23 PM, address@hidden wrote:
> Hi All,
>
> I've implemented CMake <http://www.cmake.org/> build support for GSL. As
> you probably know CMake is a popular alternative to autotools. It is used
> in many open-source projects including large ones such as KDE, LLVM and
> Blender (http://en.wikipedia.org/wiki/CMake#Notable_applications). I won't
> go into details describing benefits of CMake, there is plenty of
> information on the web, e.g. this article <http://lwn.net/Articles/188693/>.
> My particular interest was in building GSL with the Visual C++ compiler.
>
> The CMake build script for GSL is available at
> *https://github.com/ampl/gsl/blob/master/CMakeLists.txt
> <https://github.com/ampl/gsl/blob/master/CMakeLists.txt>*. It's just a
> single file that needs to be put in the top GSL directory.
>
> I've ported most of the autoconf platform checks to CMake and implemented
> extraction of various information such as version and lists of source files
> from autoconf and automake files. This way the CMake script requires little
> maintenance and can co-exist with the current GSL automake build system.
> Changes to the automake files like adding files and additional
> subdirectories holding convenience libraries don't require changes to
> CMake files
> unless there is a modification of the project structure. The config.h file
> produced by CMake is identical to the one produced by the configure script
> to make checking the consistency of platform checks easy.
>
> Out-of-tree builds and tests are supported. I've tested the script on Linux
> and MacOS X with gcc and on Windows with Visual C++ (both nmake and Visual
> Studio builds work).
>
> P.S. I sent this email to gsl-discuss some time ago, but it didn't come
> through, so I'm copying it here.
>
> Best regards,
> Victor