search

blitzpp / blitz

Blitz++ Multi-Dimensional Array Library for C++
https://github.com/blitzpp/blitz/wiki
Other
406 stars 84 forks source link

Create CMake Build #4

Closed citibeth closed 5 years ago

citibeth commented 8 years ago

Convert from autotools --> CMake

lutorm commented 8 years ago

Is there a specific deficiency in the autotools setup that needs fixing?

citibeth commented 8 years ago

No, nothing specific. But having tried both, I MUCH prefer CMake. And I'm not the only one. When I did a Google search for "migrate CMake to Autotools," what I found instead was legions of projects moving the other way. Autotools seems to be dying a well-deserved death because it's so arcane. CMake's main claim to fame is it's not as bad as Autotools.

On Tue, Jan 19, 2016 at 12:59 PM, lutorm notifications@github.com wrote:

Is there a specific deficiency in the autotools setup that needs fixing?

— Reply to this email directly or view it on GitHub https://github.com/blitzpp/blitz/issues/4#issuecomment-172934464.

floswald commented 8 years ago

+1 for CMake

slayoo commented 8 years ago

Just for the record, if you only want to find Blitz++ library from CMake, this works:

find_package(PkgConfig)
pkg_check_modules(BLITZ QUIET blitz>=0.10)
if (NOT BLITZ_FOUND)
    ...
floswald commented 8 years ago

That's actually true. I use it that way as well. So for users there is not much to gain. I just thought to develop the library a cmake build would be useful.

On Saturday, 23 January 2016, Sylwester Arabas notifications@github.com wrote:

Just for the record, if you only want to find Blitz++ library from CMake, this works:

find_package(PkgConfig) pkg_check_modules(BLITZ QUIET blitz>=0.10) if (NOT BLITZ_FOUND) ...

— Reply to this email directly or view it on GitHub https://github.com/blitzpp/blitz/issues/4#issuecomment-174218649.

youngmit commented 5 years ago

CMake is more cross-platform as well. Users on Windows would have a much better experience building Blitz if there is a proper CMake config, and the developers wouldn't have to maintain VS solutions in parallel with the autotools build system. Going the way of CMake will also open the door to including Blitz++ in the various C++ package manager ecosystems that are cropping up.

youngmit commented 5 years ago

I would be happy to take a stab at this if there is any indication that it would be accepted upstream.

citibeth commented 5 years ago

Yes it would be

On Tue, Feb 19, 2019 at 14:20 Mitchell T.H. Young notifications@github.com wrote:

I would be happy to take a stab at this if there is any indication that it would be accepted upstream.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/blitzpp/blitz/issues/4#issuecomment-465272937, or mute the thread https://github.com/notifications/unsubscribe-auth/AB1cd1EojJi6NwQy1gKHnVXKzXCiz6P0ks5vPE5sgaJpZM4HH6px .

papadop commented 5 years ago

I already have one such build. Though I must say that I have not updated it recently. If you are interested it can at least be a starting point.... I need to check where the last version is and separate it from other changes but if you are interested I will make it available.TheoLe 19 févr. 2019 8:27 PM, Elizabeth Fischer notifications@github.com a écrit :Yes it would be

On Tue, Feb 19, 2019 at 14:20 Mitchell T.H. Young notifications@github.com

wrote:

I would be happy to take a stab at this if there is any indication that it

would be accepted upstream.

—

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub

https://github.com/blitzpp/blitz/issues/4#issuecomment-465272937, or mute

the thread

https://github.com/notifications/unsubscribe-auth/AB1cd1EojJi6NwQy1gKHnVXKzXCiz6P0ks5vPE5sgaJpZM4HH6px

.

—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread.

citibeth commented 5 years ago

That would be great, can you submit a PR?

On Wed, Feb 20, 2019 at 04:20 Theodore Papadopoulo notifications@github.com wrote:

I already have one such build. Though I must say that I have not updated it recently. If you are interested it can at least be a starting point.... I need to check where the last version is and separate it from other changes but if you are interested I will make it available.TheoLe 19 févr. 2019 8:27 PM, Elizabeth Fischer notifications@github.com a écrit :Yes it would be

On Tue, Feb 19, 2019 at 14:20 Mitchell T.H. Young < notifications@github.com> wrote:

I would be happy to take a stab at this if there is any indication that it would be accepted upstream.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/blitzpp/blitz/issues/4#issuecomment-465272937, or mute the thread < https://github.com/notifications/unsubscribe-auth/AB1cd1EojJi6NwQy1gKHnVXKzXCiz6P0ks5vPE5sgaJpZM4HH6px>

.

—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/blitzpp/blitz/issues/4#issuecomment-465492547, or mute the thread https://github.com/notifications/unsubscribe-auth/AB1cd_3zODfL6Bdc5gIBLyT5IZWZFeE0ks5vPRNvgaJpZM4HH6px .

papadop commented 5 years ago

This is PR #97...

youngmit commented 5 years ago

Just took the time to get myself familiar with the discussion surrounding the PR. I think this is a better starting point than I am willing to recreate on my own. I agree with the sentiment that maintaining the two build systems in parallel without modifying some of the code will result in a considerable maintenance burden and increased complexity. I first thing that I ran into making my own CMake config that was particularly annoying was the interrogation of various compiler features, which are now several standard old (HAVE_BOOL... really?). I think in the context of a lot of the tasks that @citibeth wants to tackle to modernize the code base should probably be done in concert with a new CMake build config. Just getting rid of the vast majority of the stuff in the config headers that aren't standard in C++11 is a good start and should yield a much simpler CMake. Not sure how we could effect that with manageable PRs though.

citibeth commented 5 years ago

If we have a working CMake build I don’t want to maintain the old build going forward

On Sat, Feb 23, 2019 at 15:31 Mitchell T.H. Young notifications@github.com wrote:

Just took the time to get myself familiar with the discussion surrounding the PR. I think this is a better starting point than I am willing to recreate on my own. I agree with the sentiment that maintaining the two build systems in parallel without modifying some of the code will result in a considerable maintenance burden and increased complexity. I first thing that I ran into making my own CMake config that was particularly annoying was the interrogation of various compiler features, which are now several standard old (HAVE_BOOL... really?). I think in the context of a lot of the tasks that @citibeth https://github.com/citibeth wants to tackle to modernize the code base should probably be done in concert with a new CMake build config. Just getting rid of the vast majority of the stuff in the config headers that aren't standard in C++11 is a good start and should yield a much simpler CMake. Not sure how we could effect that with manageable PRs though.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/blitzpp/blitz/issues/4#issuecomment-466690664, or mute the thread https://github.com/notifications/unsubscribe-auth/AB1cd44Y7bI4-ENrtnQ82rOoU2uZKuh5ks5vQaU5gaJpZM4HH6px .

slayoo commented 5 years ago

this is addresed in #97, #123 and #124