Xcode Project #75
Xcode Project #75
Conversation
|
awesome job man, thanks a lot. tried to replace in my Apps current xhyve with your one built from source, worked fine, but had no luck without sudo yet. |
|
Great, will try it. |
|
Thanks! I think an Xcode project is perfectly fine for those working in Xcode. It will however have to stay in sync with the project Makefile. xhyve currently only depends on the Xcode Command Line Tools and not everyone wants to pull in a multi-gigabyte IDE (e.g. homebrew). What seems to be currently missing are all the optimization (especially LTO) and compiler warning settings. See |
|
Actually, I think that after taking this change, the followup should be the removal of the Makefile. This is an OS X project, and as you said, all that's required are the Xcode command line tools. This builds fine with xcodebuild. As for compiler warnings, actually the warnings that I set look stricter than the ones that were in the Makefile. Are there any that I'm missing? Please point them out, and I'll update. |
xhyve/src/dbgport.c:51:27: error: redefinition of 'sin' as different kind of symbol
static struct sockaddr_in sin;
^
In module 'Darwin' imported from xhyve/src/dbgport.c:30:
/usr/include/math.h:343:15: note: previous definition is here
extern double sin(double);
^
xhyve/src/dbgport.c:126:2: warning: implicitly declaring library function 'sin' with
type
'double (double)'
sin.sin_len = sizeof(sin);
^
xhyve/src/dbgport.c:126:2: note: include the header <math.h> or explicitly provide a
declaration for 'sin'
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
|
Updated for LTO per xez's previous comment. I also adjusted the compiler warnings a bit such that we now build with -Werror as well. Please comment if you think anything else is needed. |
|
I'm not super keen on removing the makefile; could we perhaps replace the all/default target with invoking xcodebuild instead? |
|
I don't personally use Xcode to work on xhyve. I would appreciate leaving the Makefile. |
No. |
|
@jeremyhu FWIW for many of us the use of OSX is merelly instrumental as we use it to target linux workloads mostly. I can say for myself that i never needed xcode for anything. It makes sense to suport xcode in order to increase our "audience" surface (and to ease stuff like @rimusz UI front-end, etc), but deprecating Makefile support (to which ALL, or most, of us are cozy by definition, (unlike, say to xcode), is IMHO a step too far. just my .2 €uros. |
|
It also makes more sense to build the project using make as external build system for the xcodeproj (see https://developer.apple.com/library/mac/documentation/Porting/Conceptual/PortingUnix/preparing/preparing.html). This way, you don't have to synchronise Makefile with xcodeproj every time a change to build options is made. |
|
You don't need to Xcode (the GUI IDE) in order to make use of the build system (xcodebuild). Many people don't use Xcode as their primary IDE, but it is a far superior build system than manually maintaining Makefiles and offers a lot that the community could leverage for increased test coverage and configuration. If you really want to keep the Makefile, then I'd rather just see it call xcodebuild. |
|
@jeremyhu - IMHO It fully makes sense to have support for xcode(build) but it would be suboptimal that it come at the cost of eventually allienating those of us who, right now, have zero expertize and know-how on it (but have years or decades of know-how on how to grasp Makefiles, which i suspect are the majority). OTOH this can be overcome mostly by attaching proper documentation to this patchset and instrumenting most/all of the xcodebuild calls via the plain/stock Makefile as that would, i suspect, make everybody happy. |
|
@jeremyhu xhyve is an OS X-specific technology, also Xcode is the same. However, if you keep the Makefile, xhyve is possible to build in the Linux (Ubuntu wily in Docker). and,
Build perfectly. These will possible build in Linux using the framework of OS X. If remove Makefile, such a hack will become impossible. |
|
Ah, good point regarding cross-platform building. In any event, it should be simple enough to maintain both build systems in parallel. |
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
|
This was merged into https://github.com/xhyve-xyz/xhyve |
|
I'm against switching to the Xcode build system, because Makefiles are the easier solution for a project as simple as this one, and they are understood by more people, which is especially true for systems programmers. I could be convinced into having an Xcode project on the side that doesn't actually use the Xcode build system, but invokes "make" for building. This way, we don't have to maintain to build systems, and Xcode users can still make use of their IDE directly. That being said, it should be easy for any Xcode user to just keep a local Xcode project... |
|
There's not really a point in using an Xcode project if you're just going to have it invoke make. Using the xcode project is much cleaner for dealing with entitlements, code signing, embedded Info.plist, etc. |
|
I recall transmission having both a xcode project and a makefile (autoconf/cmake), could be worth having a look at how they co-exist: https://trac.transmissionbt.com/browser/trunk#Transmission.xcodeproj |
This change introduces an Xcode project for easier development. It includes release, debug, and asan build configurations and sets up the build executable with appropriate entitlements as described in issue #60. It additionally pulls in changes from pull request #55 (initial man page) and installs it.