IMHO sourceforge offers more infrastructure ( home page, mailing list etc ) but in the end it does not matter much. I'm using github myself for new projects - but doing a migration of a project that runs since > 20 years successfully and is already part of any distro ( including buildroot ) ...
SVN access was horrible slow with sourceforge, but since using git I do not notice any difference between working with github or sourceforge projects. Merge/Pull Requests are a git feature - both hosting platforms support them.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2021-03-09
I'm also interested in this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm also willing to help with the cmake port if the author is actually interested.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2021-06-24
I've been using qwt with CMake for a while, didn't know this project was moved to git and that this issue tracker existed.
My stuff is here https://github.com/biddisco/qwt
there are two branches
git-svn : is just a git svn clone of all the svn repo contents so it has all the qwt history in git form, up until the switch to git which I have not yet pulled from this repo.
svn-cmake : is a branch with my cmake stuff rebased onto the git-svn. I've just updated the readme with simple instructions on using qwt in a project with cmake.
I have no idea why the qwt maintainer didn't include all the history in the git version here, but I'll gladly rebase the new stuff onto the git-svn branch if anyone wants it all in a fresh master/develop branch. Having a git repo that starts a version 6.x and loses all the previous svn logs seems a bit cheap to me.
In fact, I will do a git fetch from this repo and rebase the new 6.x stuff onto the svn branch later ...
PS. maintainer, please consider moving to gihub.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Any good reason for moving to github - beside that you are used to it ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2021-06-25
Github has a nicer interface and I'm more likely to contribute patches to a project on github, - just because notifications of activity in projects (PRs/Issues) are something I check frequently on github, but I'm not going to visit sourceforge every day to see if anything changed here on a PR/etc.
As far as git itself is concerned - it makes no difference where the repo actually is, so keeping it on sourceforge is fine, it's only the PRs/Issues/Discussions/Wiki features that github provides that mostly look/feel better than sourceforge.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have projects on github ( https://github.com/uwerat/qskinny ) too and my conclusion is, that sourceforge actually offers more than github ( starting with a mailing list ). Moving the repository to github actually results in splitting the services to 2 places what does not make much sense to me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2021-06-24
I just read some stuff here and see that the maintainer chose not to keep the history from previous svn commits. I have therefore pushed a develop-cmake branch here https://github.com/biddisco/qwt/tree/develop-cmake
it only has the cmake stuff squashed into one commit rebased onto the current git develop branch (and a readme update commit too)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In general I discourage everyone from using any of these clones, that have been created from people that are in no way related to the project. Nobody needs yet another clone, that is going to be unmaintained as soon as the author loses the interest.
Concerning cmake support: are we talking about building Qwt itself with cmake or about building an application using Qwt with cmake ?
The second use case is of an important one and if there is something that could be added to Qwt I'm open for patches - even to add them before 6.2 is finally released ?
For building Qwt itself I do not see why this is something that is important for anyone beside the Qwt development ( = me ). And yes: I do not like qmake much myself, but I do not have access to the majority of the platforms Qwt is supposed to run and changing the existing build structure is likely to introduce build problems for users, that are totally uninterested in how Qwt is built - as long as it works.
But once Qwt 6.2 is out I'm planning to drop Qt4 support from the development branch and to introduce a c++11 requirement. For this branch I can imagine to also replace qmake by cmake.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2021-06-25
But once Qwt 6.2 is out I'm planning to drop Qt4 support from the
development branch and to introduce a c++11 requirement. For this branch
I can imagine to also replace qmake by cmake.
That's excellent!
BTW, is there an ETA for 6.2?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Because I'm the one who has to complete the work for all combinations of platforms and supported Qt versions ( Qwt is still supporting Qt4 including all sort of custom builds ! ) and to maintain it then.
But I do not want to spend any time on cmake before dropping support of outdated Qt versions - maybe < 5.6 - and making other basic decisions like at least C++11.
I already know, that I will have time for my open source projects starting with Q2 of 2022 and do not want to do major changes before. I'm doing Qwt for almost 20 years now and sometimes there is more and sometimes there is less time available.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi @rathmann , I have ported qwt to CMake and I have made sure that it builds in the most systems:
OS: Windows-2019, Windows-2022, Ubunut-16.04, Ubuntu-18.04, Ubuntu-20.04, macOS-11 and macOS-12
Compilers: 5.4.0<=GCC<=11.2.0, MSVC (Visual Studio 2019 and 2022), AppleClang (XCode-13.2 and XCode 13.3)
Qt: from 5.5.1 to 6.3.0
The repo is here: https://github.com/MehdiChinoune/qwt
The tests are here: https://github.com/MehdiChinoune/qwt/actions/runs/1801547094
The port is not complete still missing tests, examples and playground which are not a big deal. I will complete them if you are open to incorporate it into your repo.
One issue is that it requires recent CMake >= 3.16, but I think cmake is easy to install anyway (snap, flatpak, pip, apt-ppa, official-tar-installer)
Last edit: Mehdi Chinoune 2022-05-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please keep it mind: which tool is used for building Qwt is more or less uninteresting - as long as it gets the job done. But applications might use cmake or qmake and Qwt should support both. This is not the case at the moment because cmake support is missing. But dropping qmake support in favor of cmake doesn't make anything better.
Also: as long as a new build system does not support Qt4 it is no option for any of the branches where Qt4 has not been dropped ( at the moment all ! ). And as I have not yet started working on the next major version of Qwt I'm not sure what to do with your cmake patch beside parking it in the patches section for a while.
But dropping support for < Qt 5.6 will make the qmake project files much simpler - hopefully to a point, where https://pypi.org/project/qmake2cmake/ can offer something reasonable. This is why I believe, that dropping Qt4 and moving to at least C++11 should be done first.
When this will happen is not decided yet. I have a couple of open source projects and do not like to jump between them all the time. But as soon as I have scheduled 2 weeks exclusively for Qwt there will be substantial progress.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can help too.
Consider moving the project to GitHub.
Moving to git has aready been done, but what would be the point in moving to github ?
IMHO sourceforge offers more infrastructure ( home page, mailing list etc ) but in the end it does not matter much. I'm using github myself for new projects - but doing a migration of a project that runs since > 20 years successfully and is already part of any distro ( including buildroot ) ...
SVN access was horrible slow with sourceforge, but since using git I do not notice any difference between working with github or sourceforge projects. Merge/Pull Requests are a git feature - both hosting platforms support them.
I'm also interested in this.
I've started some work here
https://github.com/ericriff/qwt
Feel free to contribute :)
I'm also willing to help with the cmake port if the author is actually interested.
I've been using qwt with CMake for a while, didn't know this project was moved to git and that this issue tracker existed.
My stuff is here https://github.com/biddisco/qwt
there are two branches
git-svn : is just a git svn clone of all the svn repo contents so it has all the qwt history in git form, up until the switch to git which I have not yet pulled from this repo.
svn-cmake : is a branch with my cmake stuff rebased onto the git-svn. I've just updated the readme with simple instructions on using qwt in a project with cmake.
I have no idea why the qwt maintainer didn't include all the history in the git version here, but I'll gladly rebase the new stuff onto the git-svn branch if anyone wants it all in a fresh master/develop branch. Having a git repo that starts a version 6.x and loses all the previous svn logs seems a bit cheap to me.
In fact, I will do a git fetch from this repo and rebase the new 6.x stuff onto the svn branch later ...
PS. maintainer, please consider moving to gihub.
Any good reason for moving to github - beside that you are used to it ?
Github has a nicer interface and I'm more likely to contribute patches to a project on github, - just because notifications of activity in projects (PRs/Issues) are something I check frequently on github, but I'm not going to visit sourceforge every day to see if anything changed here on a PR/etc.
As far as git itself is concerned - it makes no difference where the repo actually is, so keeping it on sourceforge is fine, it's only the PRs/Issues/Discussions/Wiki features that github provides that mostly look/feel better than sourceforge.
I have projects on github ( https://github.com/uwerat/qskinny ) too and my conclusion is, that sourceforge actually offers more than github ( starting with a mailing list ). Moving the repository to github actually results in splitting the services to 2 places what does not make much sense to me.
I just read some stuff here and see that the maintainer chose not to keep the history from previous svn commits. I have therefore pushed a develop-cmake branch here
https://github.com/biddisco/qwt/tree/develop-cmake
it only has the cmake stuff squashed into one commit rebased onto the current git develop branch (and a readme update commit too)
In general I discourage everyone from using any of these clones, that have been created from people that are in no way related to the project. Nobody needs yet another clone, that is going to be unmaintained as soon as the author loses the interest.
Concerning cmake support: are we talking about building Qwt itself with cmake or about building an application using Qwt with cmake ?
The second use case is of an important one and if there is something that could be added to Qwt I'm open for patches - even to add them before 6.2 is finally released ?
For building Qwt itself I do not see why this is something that is important for anyone beside the Qwt development ( = me ). And yes: I do not like qmake much myself, but I do not have access to the majority of the platforms Qwt is supposed to run and changing the existing build structure is likely to introduce build problems for users, that are totally uninterested in how Qwt is built - as long as it works.
But once Qwt 6.2 is out I'm planning to drop Qt4 support from the development branch and to introduce a c++11 requirement. For this branch I can imagine to also replace qmake by cmake.
That's excellent!
BTW, is there an ETA for 6.2?
fyi qmake will be deprecated at some point in qt as they switched to cmake in 6.x
Nope: QBS has been dropped, but cmake/qmake remains fully supported.
But of course it can be expected that the situation might change with Qt7. Considering, that the qmake maintainer has left the Qt company ...
that and the maintenance burden its likely to go away
Also cross-compilation with qmake is broken with qt 6.x
Any news?
@rathmann Will you accept a Merge-request to support CMake buildsystem?
I don't know why the author keep rejecting contributions from community!
Because I'm the one who has to complete the work for all combinations of platforms and supported Qt versions ( Qwt is still supporting Qt4 including all sort of custom builds ! ) and to maintain it then.
But I do not want to spend any time on cmake before dropping support of outdated Qt versions - maybe < 5.6 - and making other basic decisions like at least C++11.
I already know, that I will have time for my open source projects starting with Q2 of 2022 and do not want to do major changes before. I'm doing Qwt for almost 20 years now and sometimes there is more and sometimes there is less time available.
Hi @rathmann , I have ported qwt to CMake and I have made sure that it builds in the most systems:
OS: Windows-2019, Windows-2022, Ubunut-16.04, Ubuntu-18.04, Ubuntu-20.04, macOS-11 and macOS-12
Compilers: 5.4.0<=GCC<=11.2.0, MSVC (Visual Studio 2019 and 2022), AppleClang (XCode-13.2 and XCode 13.3)
Qt: from 5.5.1 to 6.3.0
The repo is here: https://github.com/MehdiChinoune/qwt
The tests are here: https://github.com/MehdiChinoune/qwt/actions/runs/1801547094
The port is not complete still missing tests, examples and playground which are not a big deal. I will complete them if you are open to incorporate it into your repo.
One issue is that it requires recent CMake >= 3.16, but I think cmake is easy to install anyway (snap, flatpak, pip, apt-ppa, official-tar-installer)
Last edit: Mehdi Chinoune 2022-05-27
@rathmann are there any chances for cmake in the upstream?
I have added Test, Examples and Playground.
The only thing that missing is generating cmake-config file.
Please keep it mind: which tool is used for building Qwt is more or less uninteresting - as long as it gets the job done. But applications might use cmake or qmake and Qwt should support both. This is not the case at the moment because cmake support is missing. But dropping qmake support in favor of cmake doesn't make anything better.
Also: as long as a new build system does not support Qt4 it is no option for any of the branches where Qt4 has not been dropped ( at the moment all ! ). And as I have not yet started working on the next major version of Qwt I'm not sure what to do with your cmake patch beside parking it in the patches section for a while.
But dropping support for < Qt 5.6 will make the qmake project files much simpler - hopefully to a point, where https://pypi.org/project/qmake2cmake/ can offer something reasonable. This is why I believe, that dropping Qt4 and moving to at least C++11 should be done first.
When this will happen is not decided yet. I have a couple of open source projects and do not like to jump between them all the time. But as soon as I have scheduled 2 weeks exclusively for Qwt there will be substantial progress.