The Xcode 4.4 release of a few days ago on Mac Lion (10.7.4) creates MacVim builds which can't create an edit window. vim works fine, gvim just refuses to create a window no matter what you try. But it thinks it has created the window because when you try to quit it, it warns you about open windows. Please see
On Aug 2, 2012, at 4:56 PM, Manpreet Singh <manpreet.si...@gmail.com> wrote:
> The Xcode 4.4 release of a few days ago on Mac Lion (10.7.4) creates MacVim builds which can't create an edit window. vim works fine, gvim just refuses to create a window no matter what you try. But it thinks it has created the window because when you try to quit it, it warns you about open windows. Please see
On Friday, August 3, 2012 10:36:55 AM UTC-7, Chip Warden wrote: > On Aug 2, 2012, at 4:56 PM, Manpreet Singh <manpreet.si...@gmail.com> wrote:
> > The Xcode 4.4 release of a few days ago on Mac Lion (10.7.4) creates MacVim builds which can't create an edit window. vim works fine, gvim just refuses to create a window no matter what you try. But it thinks it has created the window because when you try to quit it, it warns you about open windows. Please see
On Thursday, August 2, 2012 2:56:56 PM UTC-7, Manpreet Singh wrote: > The Xcode 4.4 release of a few days ago on Mac Lion (10.7.4) creates MacVim builds which can't create an edit window. vim works fine, gvim just refuses to create a window no matter what you try. But it thinks it has created the window because when you try to quit it, it warns you about open windows. Please see
I debugged an issue with the same symptoms a while ago. It happened when I ran `make` (which builds vim) with a different compiler than xcodebuild (which builds MacVim). Maybe 4.4 uses clang by default for the MacVim build -- in that case, run `CC=clang ./configure; make -j6` to build the corresponding vim binary. Make sure both vim and MacVim are built with the same compiler.
On Friday, August 3, 2012 9:59:42 PM UTC-7, Nico Weber wrote: > On Thursday, August 2, 2012 2:56:56 PM UTC-7, Manpreet Singh wrote: > > The Xcode 4.4 release of a few days ago on Mac Lion (10.7.4) creates MacVim builds which can't create an edit window. vim works fine, gvim just refuses to create a window no matter what you try. But it thinks it has created the window because when you try to quit it, it warns you about open windows. Please see
> I debugged an issue with the same symptoms a while ago. It happened when I ran `make` (which builds vim) with a different compiler than xcodebuild (which builds MacVim). Maybe 4.4 uses clang by default for the MacVim build -- in that case, run `CC=clang ./configure; make -j6` to build the corresponding vim binary. Make sure both vim and MacVim are built with the same compiler.
> I debugged an issue with the same symptoms a while ago. It happened
> when I ran `make` (which builds vim) with a different compiler than
> xcodebuild (which builds MacVim). Maybe 4.4 uses clang by default for
> the MacVim build -- in that case, run `CC=clang ./configure; make -j6`
> to build the corresponding vim binary. Make sure both vim and MacVim
> are built with the same compiler.
Yes, "CC=clang ./configure; make -j6" works. But *jeez* it is annoying
that special steps have to be taken.
Plus, during the compliation of the Vim binary, all sorts of warnings
are thrown out that weren't there before. And it's annoying because I
usually want to just run the ./configuring part first. In which case, I
can do "export CC=clang" and then the configuring on a separate line,
but then I have to remember to get rid of $CC after building MacVim lest
I accidentally botch building something else.
And now my steps for building have to be different between 10.7 and up,
and 10.6 and below.
> > I debugged an issue with the same symptoms a while ago. It happened
> > when I ran `make` (which builds vim) with a different compiler than
> > xcodebuild (which builds MacVim). Maybe 4.4 uses clang by default for
> > the MacVim build -- in that case, run `CC=clang ./configure; make -j6`
> > to build the corresponding vim binary. Make sure both vim and MacVim
> > are built with the same compiler.
> Yes, "CC=clang ./configure; make -j6" works. But *jeez* it is annoying
> that special steps have to be taken.
> Plus, during the compliation of the Vim binary, all sorts of warnings
> are thrown out that weren't there before. And it's annoying because I
> usually want to just run the ./configuring part first. In which case, I
> can do "export CC=clang" and then the configuring on a separate line,
> but then I have to remember to get rid of $CC after building MacVim lest
> I accidentally botch building something else.
> And now my steps for building have to be different between 10.7 and up,
> and 10.6 and below.
Hey, has anyone else noticed that there is no need for this maneuver at all on Mountain Lion, even though it has XCode 4.4 as well? I know there's a different package of command-line tools for 10.8 than for 10.7; maybe that's the difference.
>> I debugged an issue with the same symptoms a while ago. It happened
>> when I ran `make` (which builds vim) with a different compiler than
>> xcodebuild (which builds MacVim). Maybe 4.4 uses clang by default for
>> the MacVim build -- in that case, run `CC=clang ./configure; make -j6`
>> to build the corresponding vim binary. Make sure both vim and MacVim
>> are built with the same compiler.
> Yes, "CC=clang ./configure; make -j6" works. But *jeez* it is annoying
> that special steps have to be taken.
> Plus, during the compliation of the Vim binary, all sorts of warnings
> are thrown out that weren't there before. And it's annoying because I
> usually want to just run the ./configuring part first. In which case, I
> can do "export CC=clang" and then the configuring on a separate line,
> but then I have to remember to get rid of $CC after building MacVim lest
> I accidentally botch building something else.
> And now my steps for building have to be different between 10.7 and up,
> and 10.6 and below.
> Arrgh! Apple!
Maybe a way to fix this would be to change the XCode project to use a
specific version of GCC rather than just the 'default compiler'. Then
autotools and Xcode will use the same one, right, because autotools will
pick up GCC first? I'm sure it's still not foolproof, but perhaps it's
better?
