help-gsl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: ƦOB COASTN
Subject: Re: [Help-gsl] CMake build support for GSL
Date: Sat, 17 Dec 2016 22:17:19 -0500

Greetings,

The code has been merged into https://github.com/ampl/gsl.

"The license of GSL does not restrict scientific cooperation...It allows
you to share your programs freely with others...The power of distributed
peer review and transparency of process."

In honor of the language of the philosophy, I bring you NuGets.
https://www.nuget.org/packages/gsl-msvc14-x86/
https://www.nuget.org/packages/gsl-msvc14-x64/

Syntax for CLI NuGet.exe Install:
nuget install gsl-msvc14-x86 -Version 2.2.1.2577
nuget install gsl-msvc14-x64 -Version 2.2.1.2577

Thanks,
Coast

On Thu, Dec 15, 2016 at 10:58 AM, Victor Zverovich <
address@hidden> wrote:

> Thanks for the feedback, Coast. I'm glad you've found my CMake config for
> GSL useful.
>
> Cheers,
> Victor
>
> On Thu, Dec 15, 2016 at 4:43 AM ƦOB COASTN <address@hidden>
> wrote:
>
>> Greetings Victor and Patrick,
>>
>> Regarding the repo: https://github.com/ampl/gsl;
>> I aim to release some nugets for Appveyor and Visual Studio Online
>> Continuous Integration.
>> This wouldn't be possible without these awesome modifications to the
>> vanilla GSL.
>> Victor, thanks for making GSL easily compile using MSVC2015 and Cmake.
>>
>> Thanks,
>> Coast
>>
>>
>> >
>> > >
>> > > Hi Máté,
>> > > Alright, since you are not the only one asking for this feature, I
>> added
>> > > option GSL_SHARED and implemented generation of a .def file from
>> headers.
>> > > This turned out to be pretty easy to do as the list of public headers
>> for
>> > > installation is already available and GSL uses very consistent coding
>> > > conventions. You can find the updated CMake build script in the GitHub
>> > > repo: https://github.com/ampl/gsl
>> > > MinGW is doing pretty good job at porting GNU projects to Windows,
>> although
>> > > they are using a GNU toolchain, not Microsoft's. Perhaps you can
>> discuss
>> > > your ideas there. My main development platform is Linux, so making
>> projects
>> > > more Windows-friendly other than to resolve occasional portability
>> issues
>> > > is outside of my area of interest.
>> > > Best regards,
>> > > Victor
>> > > On Fri, May 9, 2014 at 1:21 AM, Nagy-Egri Máté Ferenc <address@hidden
>> > > > wrote:
>> > > > 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/0cf47581583de7ed4ee1cf0a095066
>> af0d2f97d1.
>> > > > 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
>> > > >
>>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]