Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

move to cmake #216

Closed
ra1nb0w opened this issue Jul 30, 2019 · 6 comments
Closed

move to cmake #216

ra1nb0w opened this issue Jul 30, 2019 · 6 comments

Comments

@ra1nb0w
Copy link
Contributor

ra1nb0w commented Jul 30, 2019

Hello,
first of all thank for your effort!
I am trying to build direwolf on MacOS 10.14 and it fails and the build mechanism is not idempotent. What do you think if I re-write the build system in CMake and therefore have truly multi-platform support?

thanks

@wb2osz
Copy link
Owner

wb2osz commented Jul 30, 2019

Adding new features to 3 different Makefiles (Linux, Windows, Mac OSX) is a maintenance headache. It would be nice to have a single build recipe to handle all platforms but I don't want to go down the autoconf road. Too complicated and too many bad experiences with it.

The Mac OSX case is the most problematic. I don't have a Mac, the build tools seem to keep changing and people tell me contradictory things.
The Linux Makefile, in the dev branch, already has a bunch of conditional stuff for FreeBSD and OpenBSD. I'm not happy with the current state.

I would consider cmake if:

(1) It is universally available everywhere (including FreeBSD, OpenBSD, Cygwin, etc.) using the standard package installation process (yum, apt-get, and so on). Users should not have to build cmake from source.

(2) The implementation handled all of the special cases such as different compiler options based on compiler version (e.g. is -fastmath available) and target hardware (e.g. -msse or -mfpu=neon which make a big difference in performance).

(3) It can handle situations where the same source is compiled multiple times with different conditional compilation depending on where it is used. For example, some library might have a main program which is used for unit test.

(4) Can handle other complications that might arise.

@ra1nb0w
Copy link
Contributor Author

ra1nb0w commented Aug 1, 2019

  1. yes, cmake is becoming the standard; anyway debian prefer debian/ folder with debhelper or similar.
  2. I wrote a multi-platform cpu flags discovery so we can use that (from sse2 to avx512 and neon)
  3. yes
  4. yes, and this is why 1

I will prepare a prototype (no deadline please) and we will discuss that.

@ra1nb0w
Copy link
Contributor Author

ra1nb0w commented Aug 16, 2019

Do you prefer that I use -dev or -master?

@wb2osz
Copy link
Owner

wb2osz commented Aug 16, 2019

"dev" branch because that is where all development is happening.

@wb2osz
Copy link
Owner

wb2osz commented Nov 24, 2019

This has been merged into the dev branch.
Feedback, from users of many different operating systems, has been positive.
Thanks for all the hard work you put into this.

@wb2osz wb2osz closed this as completed Nov 24, 2019
@ra1nb0w
Copy link
Contributor Author

ra1nb0w commented Nov 25, 2019

thank you.

TODO:

  • probably remove the inner folder created by cpack on the zip for windows
  • rework deb/rpm packaging (ask to the respective maitainer)
  • rewrite macOS build documentation. Now the procedure it is the same of GNU/Linux and to install dependencies you can use either macports or homebrew; for example
    sudo port install cmake portaudio [hamlib gpsd] then build direwolf as always.
    From 1.6 I will push direwolf to macports therefore the installation will be easier: sudo port install direwolf.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants