Although what the title says, the point of this thread is not say we should remove the option completely, but to open the discussion about developer experience with that building option and gather thoughts about the need for that to continue to be maintained and for we to document a new more stable option for people trying to work in the compiler with Xcode.
For context on why this is an important discussion is that given new comers to the project are often familiar with Xcode and that is the first option they try when first setting up things to build the compiler for the first time and start digging into the code. But given that —xcode is not as stable as ninja build it is very common people hit all kinds of issues when trying out that option which for beginners it becomes a first barrier get a first contribution in. We can see that over the last few years lot of threads of this forums from people having issues with building the compiler with —Xcode. Some examples:
In my personal experience and also from talking to others as well, using the Xcode build was always unstable and often either some thing would make it not work anymore.
Even recently we could see some threads from people from the Swift Mentorship Program trying to build the compiler and hitting those issues on the Xcode build.
So with that said it is fair to state that the --xcode build option doesn't offer a good developer experience, which is the goal we are aiming for.
And aiming for a better developer experience, recently Erik shared a way to use Xcode with ninja which seems to work pretty well and we actually have the stability of the ninja build and the nice IDE experience from Xcode. Which is the first option we have, and the idea would be documenting that in the started guides and remove mentions of the --Xcode so that becomes the "recommended way" for people to use.
So we want to hear your thoughts about that!
Questions about --xcode option
If that becomes the new recommended way for developers to use Xcode, would that option still be useful? There is a lot of code(including work arounds) in build script and cmake files to maintain this option so deprecate that option would be a clean up on that area.
How many people actually rely on --xcode build? And for people that rely on it, what is the aspect that you rely on that we can't achieve with using Xcode with ninja?
What do you think would be the impact of deprecating or removing that option completely?
I think those are the most important questions I could remember, but feel free to raise more.
Before we wrap up, it is important to note that the goal of this discussion is not to say we should remove this flag, but to propose a new recommended way to use Xcode in development for new contributors that improves developer experience and if that makes --xcode not useful anymore, and if that is the case if is still worth the work of maintaining it.
So the actual first action steps for now would be just update the GettingStarted Guides to not recommend that option anymore.
Let us know your thoughts and concerns about that topic.
With Best Regards,
Luciano
I still rely on --xcode working to create an Xcode project that can index, navigate, and edit, but not build, the compiler, since I use a separate ninja configuration for that. So I'd be fine with --xcode being relegated to creating an edit-only project. Erik's instructions for integrating Ninja builds with Xcode still rely on --xcode working to create the initial Xcode project, so his approach wouldn't be viable if we completely remove the --xcode option IIUC.
For a long time, a lot of the problems with the Xcode build have come from the way we set up the build system to cross-build components for the target architectures, such as the runtime, standard library, and other bundled Swift libraries. Longer-term it would be great if we could move those out of the compiler build system so they can be developed and built separately. However, in the short term, what if we make it so that --xcode only sets up build targets for the compiler itself, and maybe the runtime C++ code targeting the same host as the compiler? My primary concern using Xcode is getting good C++ navigation support; I haven't found another IDE that does as well with the LLVM or Swift codebases.
Have you considered using CLion? I have been using it for a while and it works great, even better than Xcode I would say (some of the nice things I like about it is being able to see the inferred types of variables inline, names of function parameters appearing alongside the arguments in a call, etc and you have your debugger, breakpoints and all the advanced features as well).
One big downside of it is that it is paid (although it seems reasonably priced to me and certain people like students can get it for free) so I guess we cannot recommend it as one of the "official" ways of building the project.
We have [CMake] Refactor --xcode To Imply --skip-build · Issue #60746 · apple/swift · GitHub to track some actions we are planning to take in order to improve the default behavior of --xcode flag in compiler development workflow. But one point we are not sure is how does this flag is used in stdlib development workflow(if used at all) and how those changes could break stdlib developers workflow? cc @nnnnnnnn@lorentey@Alejandro
In that same line of question what is the most common workflow for someone working on stdlib? Is there any starter guide similar to the compiler one?
Also, in a more general way if people have concerns on how those changes could affect/or break either their swift compiler development workflow or LLVM as Joe mentioned, let us know!
That's good to hear. Last time I tried to use CLion with LLVM or Swift I couldn't get it to configure correctly at all. As an Apple person, though, I have some amount of moral obligation to eat our dogfood to the degree it's practical to do so.
Speaking only for myself here, I'm not using the --xcode flag at all -- I just use the default CMake/Ninja-based workflow to work on the stdlib. I edit stdlib source files with Emacs. (Note: this is not at all a value judgement -- I generally much prefer to use Xcode to edit Swift sources, but in the special case of the stdlib, this wasn't really a viable option so far. Emacs does work very well for editing gyb files.)
I think the compiler's starter guide generally also applies to the stdlib, although future work may diverge them a bit. (One thing I'd dearly like to see is the ability to build the stdlib as a standalone SwiftPM package.)
Direct interactions with CMake or Ninja do not spark joy for me personally, so I prefer to just build & test my changes with build-script instead of figuring out individual targets to manually rebuild. I'm sure other folks are making more reasonable life choices, though.
If you have ideas to make --xcode work better, please go for it! I would love to have a more modern editing workflow for my own use & to recommend to others. I don't think I'd often build the stdlib from within Xcode (I generally prefer to stick to the same build tools that are used to build the official toolchains) but being able to edit sources (and maybe do quick smoke builds) would be wonderful.
Just like Karoy and David, I don't use --xcode. I tried to get it to work a long time ago, but having failed then I never gave it another thought. I use Xcode to edit individual stdlib files, with minimal editor help. I use build-script to build, with direct lit invocations for testing. It's not great but I have enough notes to survive it.
Just curious, how does lldb debugging works on this setting?
In the compiler workflow, there is a way to integrate ninja builds with Xcode to get the stability of ninja builds with a nice editing experience of Xcode and people who had setup it to work in compiler said it works great, so we wonder if that could work for stdlib as well.
--xcode has not been stable for quite some time, we often have to make lots of workarounds, but last week(the most recent I've tried) was not working at all =[
That does sound good. Things usually fall apart when it comes to dealing with gyb files, but even limited support would be a lovely productivity boost. (Not that Emacs is a bad experience -- it has great code completion (hippie-expand is not smart, but it's eminently pragmatic), the indentation rules are tailored to the stdlib coding conventions, and the editing experience overall is very hard to beat. But I'd much rather use a single code editing tool than two, and tbh Emacs (& vi) do feel like tools from the 80s -- they might be polished to perfection, but they're still very much tools of their time.)
I think I will spend some time experimenting with an Xcode based workflow the next time I'm in between urgent projects.
As someone with less experience with the Swift compiler and pivoted from iOS dev to compiler dev, Xcode is my preferred way of editing Swift source files. Xcode also has reasonable support for editing C++ files, which allows me to locate the code I'm trying to find using a familiar UI. I would certainly like to use the --xcode option, but most of the times I tried to use it, something about it is broken (as mentioned in the initial post). In fact, I found this post while trying to find a solution to fix --xcode for my new Mac.
I run all the unit tests through command line, but during active development I find it more convenient to setup/reuse/enable/disable breakpoints through Xcode, and quickly change which command line argument I pass to swift-frontend/other targets when I test my changes on the few small sample program I use to verify/debug the thing I'm currently working on. I can probably setup command line alias for all the things I need to do, but Xcode allows me to just click a few buttons and quickly switch between the different arguments I need to pass (especially path to the sample source files).
The ninja + Xcode workaround works, but needing to create a new target and scheme for everything I want to run is... very tedious, and I don't like the fact that I have to find/type the correct path to everything. It's also a discovery problem: with an automatically generated project through --xcode, I can see all the things I could run, and make a guess about which scheme might fit my needs. For manual setup, I have to set one up, try it, and repeat until I find the right target to run...
Some times I forgot to rebuild both ninja and Xcode and find myself debugging an old build, so in conclusion, building using ninja + auto config Xcode project for ninja would be what I wish for.