[cfe-dev] [LLVMdev] is configure+make dead yet?

[Jordan Rose]

On Jun 28, 2012, at 6:45 AM, Bill Hoffman wrote:

> On 6/28/2012 8:31 AM, Jean-Daniel Dupas wrote:
>> My answer was about "CMake developers are aware of the inferior quality of the Xcode generator, but they say that there is little interest from the Xcode users."
> 
> I disagree.
> 
> The CMake devs say that it is the best that can be done with what Xcode 
> can do.  For example in Xcode you can not have a target depend on an 
> arbitrary file.  This makes it impossible to do some of the stuff that 
> CMake needs to do in order to build projects correctly.  To compensate 
> we use custom targets that fall back to makefiles and make called form 
> Xcode.  I don't think we are uninterested.  If there were specific 
> complaints, and examples given in working Xcode projects we would adapt 
> CMake.  The Xcode generator in CMake is able to build all of our test 
> cases and display all of the sources for the project in Xcode.  It does 
> use make for some bits that Xcode can not do.  However, I am not aware 
> of things that are broken.
> 
> -Bill

I want to stay out of this as a discusser, but I'll offer my current experience in Xcode:

One of my machines has a single Xcode project containing both LLVM and Clang; the other has two projects contained in a single workspace. The latter does not build the Clang regression tests correctly; it is printing "PASS" outputs as well as "FAIL" outputs and Xcode is treating these messages as failures.

Neither project includes the regression test files by default, even though there's a target to run them. I had to add the test directory to my workspace manually.

There are files missing from the generated project files: header files and tablegen files that live in lib/ instead of include/. There is little point in adding these manually to the project because any changes I make are overwritten when the projects are regenerated (which happens whenever someone touches any CMakeLists file). It would be nice if CMake tried to /merge/ project files instead of /replacing/ them, but then again I understand the difficulty of working with a closed format.

This is probably a Clang issue more than a CMake issue, but I can't find an easy way to only run some tests. Probably I can set TESTDIRS in the Build Settings, but I haven't tried it yet. I can't make a separate custom target because (again) the whole project file is regenerated, not merged, when CMake sees an update.

The fact that CMake uses make for "some bits that Xcode cannot do" is what prevents the Xcode dependency checking from working properly -- the link phase of pretty much /every/ target is implemented using make. It would be /very/ nice to avoid this.

All of that said, /having/ an IDE is an improvement over TextMate (which I used on my memory-limited home laptop for a year or two). I haven't noticed such slowdown in building compared to make -- both are "fast enough" for incremental builds, and both take long enough for large rebuilds that I quickly go check cfe-dev or something.

Then even apart from working for Apple, I'd prefer Xcode over some other IDE on OS X because it feels like the rest of the system. Cross-platform IDEs generally do a terrible job of emulating OS X's standard UI behaviors that I've come to expect everywhere.

And all of /that/ said, I /also/ have a make-build set up as well, for (a) running just some tests, and (b) testing both build systems when I add or remove a file.

I'm not sure if any of this helps a final plan of action, but it's one more set of data to work with.

Jordan