Skip to content

Fixes to Makefile.macosx #14

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

Closed
wants to merge 6 commits into from
Closed

Fixes to Makefile.macosx #14

wants to merge 6 commits into from

Conversation

mistermatt2u
Copy link

  • Replaced logic that determines what version of OS X SDK is installed, and where. Assuming the existence of /Developer produced make errors on 10.11. This is likely due to the fact that XCODE installs to /Applications by default (when installed via App Store). Use of the xcrun tool seems to be a more reliable way to make the determinations.
  • Replaced instances of /opt with /usr. Assuming the existence of /opt caused make errors for 10.11. According to 'man hier', the file system hierarchy information, /opt is not used on OS X. If there is a standard location for shared libraries, it is maybe /usr/local/lib. (Reverted -- see commit f71eab3)

…d, and where. Assuming a location of /Developer produced make errors on 10.11. This is likely due to the fact that XCODE installs to /Applications by default (when installed via App Store).

- Replaced instances of /opt with /usr. Assuming the existence of /opt caused make errors for 10.11. According to 'man hier', the file system hierarchy information, /opt is not used on OS X. If there is a standard location for shared libraries, it is /usr/lib.
@mistermatt2u
Copy link
Author

I should note that I did understand the comment "System SDK's (10.8 - 10.10) must be located here to make use of them." in the file. However, I think my logic makes a successful compile more likely. At least, it makes it easier (without nested if) to reliably determine the SDK information. This commit was a result of me trying to work thru errors to get this to compile on my OS X 10.11 laptop.

- The file gen_fff is created as part of the build process. However, if the build fails (or maybe even if it doesn't), the gen_fff file is not cleaned when running 'make clean'.
- Removed 'echo' comments about SDK needing to be located in /Developer. This is no longer the case after commit b15bf7d.
- Apparently macports likes to put includes in /usr/local/include and not /opt/local/include like maybe it should. So we shouldn't change /opt to /usr for the portaudio part of the makefile. This reverts those changes, and (apparently) allows the portaudio portion to compile on 10.11
- Remove statements that set the architecture selection that is passed to the compiler. The statemets seemed to only be an opportunity to cause build failures due to manual setting of the architecture. Perhaps it is best to let the compiler do that on its own.
- Re-work logic to determine if make should build gps tracking support. gpsd support can now be tested.

- Temporarily remove the output file of unit test 'atest'. Make was erroring out when completing that target for an unknown reason.

- Direwolf now compiles sucessfully on OS X 10.11
@mistermatt2u
Copy link
Author

With all of the above commits in place, direwolf compiles successfully on my mid-2012 Macbook Air running OS X 10.11.2 El Capitan. gpsd and portaudio packages are both required to be manually installed by MacPorts prior to building direwolf.

@wb2osz
Copy link
Owner

wb2osz commented Nov 24, 2019

No longer applicable. The 'dev' branch is now using cmake.

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

Successfully merging this pull request may close these issues.

2 participants