MacOS X XCode project files for building frameworks

[Brian Olson]

Attached is an archive of files that should work to drop into an svn checkout and build things on Mac. It works on my machine with OS 10.5 and XCode 3.1.

This should get you started if you have an svn cheockout protobuf-read-only:

cd protobuf-read-only

tar jxf ~/Downloads/macosx.tar.bz2

open macosx/protobuf.xcodeproj

This works for me better than the version-hardwired script at /autogen.sh :

macosx/autogen.sh

The important bit is here:

macosx/protobuf.xcodeproj/

Right now it builds two frameworks, one 'protobuf.framework' and 'libprotoc.framework'. It also builds `protoc` dependent on these frameworks. Building and running the tests should probably be added.

I'd like to hear from other Mac users and hopefully this will be useful and maybe make it into the standard source tree or allow for MacOS X binary distributions in a nicely bundled fashion.

[bolson]

Upon further investigation, I discovered that this approach is
incomplete.

The include paths don't work out. Normal things like this:
#include <google/protobuf/message.h>

work when installed under "/usr/local/include/google/..."
But, they fail because framework searchpaths would want:
#include <$frameworkname/message.h>

So, all the #includes need to be conditional like this
#if __APPLE__
#include <GoogleProtobuf/message.h>
#else
#include <google/protobuf/message.h>
#endif

and that would also need to be changed for things generated by protoc.

If only macro substitution worked in #include , I'd #include
<##PROTO_BASE##/message.h>


XCode build project still has the advantage of being able to produce a
fat binary that simultaneously includes ppc, pp64, x86 and x86_64
object code. Maybe I should convert the framework targets to producing
static and dynamic libraries. #include installation is left as a
separate exercise.

>  macosx.tar.bz2
> 11KDownload

[Alkis Evlogimenos ('Αλκης Ευλογημένος)]

If you add the conditional includes wouldn't that break protobuf installations under /usr/local?

--

Alkis

[bolson]

Yeah, just putting it under __APPLE__ would be too general and the
same file wouldn't be able to be installed under /usr/local

I still think frameworks are a good idea. Now I'm imagining a script
that copies the headers into the framework bundle while filtering to
do the edits to the #include paths.
s/#include <google\/protobuf\/(.*)>/#include <GoogleProtobuf\/\1>/g

protoc could have a flag --framework or so to emit framework style
#include lines.

This still has the downside that something using protobufs and trying
to build portably on MacOS and other platforms would now have
different #incude lines depending on whether they were building with
frameworks or simple paths.

It's still awkward and imperfect. Maybe I will just go back and hack
up XCode files to build fat binary dynamic libraries. That would be
unmitigatedly useful.

On Jul 28, 6:28 am, "Alkis Evlogimenos ('Αλκης Ευλογημένος)"

[Kenton Varda]

On Sun, Jul 27, 2008 at 11:31 PM, bolson <brian...@gmail.com> wrote:

Upon further investigation, I discovered that this approach is
incomplete.

The include paths don't work out. Normal things like this:
#include <google/protobuf/message.h>

work when installed under "/usr/local/include/google/..."
But, they fail because framework searchpaths would want:
#include <$frameworkname/message.h>

So, all the #includes need to be conditional like this
#if __APPLE__
#include <GoogleProtobuf/message.h>
#else
#include <google/protobuf/message.h>
#endif

This sounds like a recipe for build breakages.  Could we just post-process the public headers *after* the library has been built?

 

and that would also need to be changed for things generated by protoc.

This could be done with a new option to the C++ code generator.  There is already such an option for adding MSVC-style "dllexport" attributes.  Check out cpp_generator.cc.

If only macro substitution worked in #include , I'd #include
<##PROTO_BASE##/message.h>

IIRC, macro substitution *does* work in #include.  But I'd still rather post-process the headers.

 

XCode build project still has the advantage of being able to produce a
fat binary that simultaneously includes ppc, pp64, x86 and x86_64
object code.

Can't you accomplish that with the current makefiles by just doing something like this?

./configure CFLAGS='-arch i386 -arch ppc'

(add more flags for pp64, x86_64, etc.)

[Matt]

I don't understand the appeal of a framework in this case. Whatever
you do, please don't break the current functionality/option on the mac
of installing in /usr/local.

On Jul 28, 10:08 am, "Kenton Varda" <ken...@google.com> wrote: