CMake

[undisputed-seraphim]

Is anyone interested in CMake support? I have a WIP now, I can make a pull request if there is demand.

It comes with a drawback, though. I might have to rearrange the files in the /src folder, and possibly more. Existing Makefiles and VS projects will certainly break.

[gsjaardema]

I am interested in cmake support. .. greg

On Mon, Feb 20, 2017 at 7:25 PM Tan Li Boon notifications@github.com wrote:

Is anyone interested in CMake support? I have a WIP now, I can make a pull request if there is demand.

It comes with a drawback, though. I might have to rearrange the files in the /src folder, and possibly more. Existing Makefiles and VS projects will certainly break.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tbeu/matio/issues/53, or mute the thread https://github.com/notifications/unsubscribe-auth/AA2xDub9eRs0VJw8dI_UGoueKY50M7E7ks5reksBgaJpZM4MGzhx .

[tbeu]

Sorry, I am not a big supporter of CMake, especially not as replacement of VS project files. The autotools build scripts are pretty mature and were just recently updated to newer config templates. Thus, I do not see any added value to have CMake support.

[undisputed-seraphim]

Well Cmake doesn't just replace VS projects, it replaces all project files on all platforms.

[tbeu]

Check what the OpenMEEG devs already have done https://github.com/openmeeg/openmeeg/blob/master/cmake/externals/projects_modules/matio.cmake

[traversaro]

CMake is also convenient to support all the triplets required to create a vcpkg port of matio ( https://github.com/Microsoft/vcpkg/issues/621 ).

Furthermore, I don't think it is strictly necessary to rearrange the files in the /src directory, so there is not need to break existing build systems.

[tbeu]

Thing is, that I was aware of the tedious and still ongoing CMake support for the exiv2 lib/tool. They stopped it after several months of effort. Do not expect that all targets work out of the box. Ever tried CMake for MinGW or VS? It is painful. Sorry, I just had too many bad experiences with CMake. And once it is merged in the repo, it will be me maintaining it, which I simply want to avoid.

[undisputed-seraphim]

I've only had good experiences with CMake. Chances are, you're using it wrongly.

I've had a few cross-platform projects that were much easier to maintain after I moved to CMake, because the configure.ac workflow was too much work to maintain and it was easier to have CMake generate the makefiles instead.

CMakeLists has been incredibly easy to maintain as well, since it is only a handful of lines at most for small projects like this one.

By the way, CMake for VS and MingW is incredibly easy, I use it all the time... I have no idea what you're talking about.

[undisputed-seraphim]

But well, if you still don't want CMake, I guess I can always maintain it on my fork and pull changes from this upstream.

[papadop]

On 02/21/2017 05:00 AM, Greg Sjaardema wrote:

I am interested in cmake support. .. greg

On Mon, Feb 20, 2017 at 7:25 PM Tan Li Boon notifications@github.com wrote:

Is anyone interested in CMake support? I have a WIP now, I can make a pull request if there is demand.

It comes with a drawback, though. I might have to rearrange the files in the /src folder, and possibly more. Existing Makefiles and VS projects will certainly break.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tbeu/matio/issues/53, or mute the thread

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

I'm interested toif some support is integrated in matio directly. We are using an alternate github repo with cmake support and as far as I remember it was fully compatible with the existing automake/autoconf solution, without much file rearragment.

https://github.com/openmeeg/matio-openmeeg

Best regards,

Theo.

[papadop]

On 02/23/2017 03:04 AM, Tan Li Boon wrote:

I've only had good experiences with CMake. Chances are, you're using it wrongly.

I've had a few cross-platform projects that were much easier to maintain after I moved to CMake, because the configure.ac workflow was too much work to maintain and it was easier to have CMake generate the makefiles instead.

CMakeLists has been incredibly easy to maintain as well, since it is only a handful of lines at most for small projects like this one.

I concur with this message.... Integration in other projects is exactly the reason why we ported matio to cmake for OpenMEEG.

Cmake does have some problems but much less than automakre/autoconf in my experience. We are building matio for several flavors of linux, MacOS and windows (only with VC++) routinely using the cmake build system.

tHEO.

[emmenlau]

@tbeu I think this is your decision, after all you create this excellent library. And I personally like autotools a lot, so I concur with you there.

But just my two cents: I'd also be happy about cmake. For continuous integration on many platforms, it makes things easier for me. I find it super hard to read Visual Studio project files, let alone change settings in an automatic build system. I've done it (with perl), but it sucks. cmake takes away most of this pain for me. Even if its not perfect, its much better than hardcoded Visual Studio project files for me. But thats just me, I can pull the OpenMEEG cmake integration and live with that, no worries.

[papadop]

It's just a pity because the Cmake port just lags behind the master.... We are updating it regularly but we do not follow all the matio commits... Integrating the two, would not disturb autotools (they continue to work as before) and would allow an easier way to maintain the cmake port... And yes, I volunteer to maintain the port (I do it already in the OpenMEEG version, so it would not be too much of a trouble). And of course, others would be welcome...

[tbeu]

@papadop I can give you push rights if you like to maintain the cmake port.

Once there is a new release published, I also push to the official sf repo.

[papadop]

Deal.... .

[emmenlau]

@papadop I would like to start with cmake support. Could you try to update to the latest sources so that we can start testing and discussion of the integration? I think its better to start a bit early (before there is the next official release) so that we have something ready when the release comes. I can help if you can give us a start?

[massich]

Checkout this for a non invasive cmake build.

[GiulioRomualdi]

Is there any news on the possibility of using CMake with matio?

[massich]

@GiulioRomualdi check out https://github.com/massich/matio-cmake It wraps up a cmake build on matio. There's also a conda package to distribute a matio binary with cmake.

[emmenlau]

Dear @tbeu , I would still be very interested in cmake support. Its a bit sad to see that there are now a number of different cmake integrations circulating, each with their own pro's and con's. I think a number of people could give a hand for a good official cmake integration. But is that something you would consider?

[tbeu]

I do not enforce it since I am happy with the autotools + autotest(!) build on Linux and VS projects on Win. I prefer to have minimal invasive changes.

One huge effort I see is the usage of CTest for all the tests.

There is #74, #75 from you (and still WIP?) and https://github.com/massich/matio-cmake. I recently recommended https://github.com/tbeu/matio/wiki/CMake to some user of matio.

[emmenlau]

I understand that the best solution would include CTest. But since you also like minimal invasive changes, I would rather propose to make a push for a minimal, working, cross-platform CMake integration (in addition to the current autotools and autotest).

CMake can significantly help the popularity of the library because a very large number of build systems and package managers have native support for it. At the same time I would not even try to include all autotools features in CMake to avoid the maintenance overhead.

But before anything, would you be open to merge such a PR? Its really fine if you'd rather not, then I will move on and live with the VS projects.

[tbeu]

Yes, there is your PR #75, but it fails some checks and is conflicting now.

[massich]

@emmenlau have you checked https://github.com/massich/matio-cmake ? Its completely none invasive to matio and gets the job done. I know its been used by other people. It is true that not all the tests are run (in windows) but this is something we can fix. Plus now with github actions, the sync can be improved.

Adding CMake to matio, is not gonna happen and that's fine. Build system and distribution can be completely separated from the code. So instead of trying to twist tbeu's arm on the matter, it would be better to check what you miss in matio-cmake and we place community efforts there. And if we have to schedule a some sprint (remote or local) this can be done.

[massich]

@tbeu if you want me to transfer you the rights of matio-cmake I've no problem in doing that (you could add mee as collaborator) or I could add any change through PRs.

[emmenlau]

Adding CMake to matio, is not gonna happen and that's fine. Build system and distribution can be completely separated from the code.

@massich I disagree from the bottom of my heart. I have more than 10 years experience in maintaining build systems separated from the original code base. It goes well for a year, and then some people have moved on, the build system starts missing the one or other source file, problems go unnoticed, security fixes are not integrated, and eventually its dead. We have already 3 such cmake build systems (including yours) and already now 2 of them are poorly maintained.

I think we can either integrate cmake support, or its a dead horse.

[tbeu]

Adding CMake to matio, is not gonna happen

I have no problem adding CMake support at all. It is just that I do not want to maintain it and that I'd prefer minimal invasive changes only. I'll leave CTest support to you since it is of secondary priority.

Confirmed, there are now 3 people (@emmenlau, @papadop and @massich) that worked on it (independently), but still none of there contributions seem to be ready to merge.

[massich]

@emmenlau this happens if you bandle the project, then you do miss files. If you make everything automatic and allow github run the sync for you, you would always have it up to date.

[papadop]

Just to leave a comment. I'm sorry I have not finished/maintained the cmake, but I also had to move on my main stuff... The full cmake build was working at some point (with some minor stuff that could have been polished afterwards). But I must say I have been somewhat discouraged because I did not see how it would have been integrated with the main branch. I have tried to be minimally invasive, but the comment I got was that it was already too much... I already did my best to not duplicate all the testing effort by parsing the available autoconf tests, but I'd have expected to get at least some code changes to avoid having also to parse the autoconf/autoheader changes. This was not changing much the way autoconf/automake was working but was helping a lot the cmake build maintainance.

Having the two build systems requires some collaboration and some concessions (not big ones, but at least the willingness to modify a little the current code notably to add the windows import/export stuff).

I still interested in having the cmake branch integrated and not maintained separately. I probably will update the cmake branch next time I will need to build matio. I also open to share the branch with anyone willing to help maintaining it... I do believe that having/maintaining the two build systems simultaneously is possible and desirable, but we need to agree on the strategy to go there, and I do not believe that a purely non-invasive approach is maintainable on the long run.

I had (or maybe still have) a forked repository for that for a long time in OpenMEEG, and I can tell you that synchronising it always required quite some work and I doubt that any github magic can do much in understanding the autotools changes and make the equivalent with cmake. Changes breaking the build will be easier to get but everything else will probably be unnoticed (especially if the testsuite is separated as it was with the OpenMEEG version and this is why I have tried to change that with the cmake branch in matio).

This is all the more that I believe that the code changes were actually improvements. As an example, marking the exported symbols in the code is clearer/cleaner/simpler than having to maintain a separate matio.def while keeping the possibilty of keep using the matio.def. Moving the testsuite files was also a nice strutural improvement IMHO. There were also some other minor changes, but I do not believe there were that controversial.

A nice thing of the cmake port was also that it uncovered some testsuite (mostly flags problems IIRC) errors. I think all of those have been corrected in the main branch. You may think that having two build systems is redundant but my experience is that it helps making the software more robust.

[papadop]

@tbeu: No-one ever asked you to maintain the cmake port. I think there are several people that can do that. No-one even had asked to make cmake an officially supported build so that even travis&co cmake related problems (provided cmake builds are tested) could be ignored if necessary.

If the build is integrated, and people (I or others) get cmake build failure notifications, that enough to ensure an easy incremental maintainance of the build. A separate branch is just too complicated (I do not know the new github magic you refer to).

[emmenlau]

@tbeu I think its great that you are open to merge cmake support if its working. I will try to get a good, working PR ready. @papadop and @massich lets work together on this if you want/can, any help is greatly appreciated. I think the instructions from @massich are currently the newest ones, so I'll try to disect the differences between @massich's cmake instructions and the ones from @papadop and myself. Is that good?

[JohanMabille]

Hi,

I've been working with @massich on https://github.com/massich/matio-cmake (especially for the Windows part). Regarding the need for CMake, it helps A LOT for packaging, especially when the package manager supports many platforms (like conda for instance).

I agree with @papadop, having the CMake support integrated would be a better option than maintaining it in a separate branch or even a separate repo (besides of sync problems, this solution won't prevent people for developing their own CMake support instead of collaborating on a single one).

@emmenlau @papadop @massich thanks for working on this!

[tbeu]

@emmenlau @papadop @massich thanks for working on this!

I can only fully acknowledge this.

[massich]

@emmenlau you start by trying to compile matio-cmake. What was not working was to get ctest to run the windows tests.

[tbeu]

@emmenlau Are you working on CMake support right now?

[SylvainCorlay]

:+1: on cmake support. I would be happy to help @papadop @JohanMabille and @massich if things come up with cmake.

This would be very helpful to package matio on conda-forge, especially on windows.

Also, we rely on cmake for the xtensor stack and it would make it simpler for us if matio could be built with cmake, especially on windows.

[tbeu]

Thanks for considering to contribute. Last commitment I have was from @emmenlau who wanted to go ahead with CMake support.

[massich]

@SylvainCorlay pick place and date, and I'll be there either IRL or remote. But we really need to stab this one, and let the CIs work for us.

[emmenlau]

I won't have time this week but I'm happy to test PRs. Feel free to move ahead.

[tbeu]

Well, this issue is open 2 years (as of tomorrow). No need to rush this week then.

[MicheleBe]

Thanks for the interestiong discussion, I also come from the autotools world but slowly I discovered Cmake that helps me to manage in consistent way dependency also for very large system through the so call subuild pattern. At the end it is like moving from functional development to OO. It was not always trivial but the capability to integrate different platform support with installation instruction and even packaging it is really powerful. Concerning the test I understand the reluctance towards ctest, altough it it possible to wrap its behaviour in almost transparent way. I manage to handle more than 50 different projects (with different tools for testing CppUTest, Google Catch and so on) under an unique ctest project and consequently an unique dashboard.

[tbeu]

@MicheleBe Thanks for your comments. Feel free to test #107 (still lots of open issues to tackle before ready to merge).