Re: My swarm compile for OSX

[Marc-Antoine Parent]

> It only has fixed path at the compile time of the old style library 
> into a framework.  If you are writing new code to use the library you 
> can use the Apple conventions. Basically if you want to use legacy 
> UNIX style includes you have to use a legacy UNIX style build for that 
> bit of code, but not for its subsquent use.  It strikes me there may 
> be some issues with includes in headers?

Yes, there is... Sometimes. That's a bit tricky: I'm not sure I always 
understand what works or does not. Interdependence between headers in 
.../Headers usually seems to work; but as I remember it, headers in 
.../PrivateHeaders which rely on headers in .../Header are in trouble.

My issue is the following: A lot of libraries (Tk being a good case in 
point) have a _huge_ codebase of other legacy programs that depend on 
it. It is bizarre to me that the "correct way" to port these libraries 
to Mac makes it necessary to either modify the source code of all 
client code (which might be a huge or disparate codebase), or build 
them in a way that violates the abstraction provided by frameworks in 
the first place (i.e. specifying the framework's location and/or 
version in the -I, -L flags.)


> > Also, I once used such a path in ProjectBuilder; as it wants to 
> > resolve
> > symlinks, my -I/Library/Frameworks/Tk.framework/Headers became
> > -I/Library/Frameworks/Tk.framework/Versions/8.4/Headers! Now that
> > defeats the purpose even more... Really, I feel -F should do the work
> > for us without changing clients. Hey, care to start a petition on this
> > with me? ;-)
>
> I am not sold yet.  There was some powerful reason for doing it the 
> way they did, until I understand that, I would rather keep quiet.

OK. Then do you agree we should ask the question cogently on Apple 
networks (Do they see this as an issue, etc.) ?

> > > Now you right back into the standard UNIX mess which
> > MacOS X is
> > > designed
> > > to get away from.  I quite agree that
> > /usr/local/appname is the way to
> > > go
> > > on UNIX with maybe a symlink for the default.
>
> > Heh! Someone should build a package manager and package database for
> > Darwin frameworks ;-)
>
> I think the GNU-Darwin project did this.

Is that so? I'll take a look, but I'm not convinced their packages use 
frameworks.

> > OK. Will try to remember where this happened and come back.

BTW, I also sent the info to Apple.

> I am making a distinction between files which contain code in C, 
> ObjectiveC etc which are compiled and end up as object code in the 
> libraries and executables on the one hand, and build system files, 
> which are mostly part of autoconf and automake and libtool and which 
> orchestrate the build but leave no trace in the finished product.

I know. I was pointing out that, in a crossplaform project, both are 
pretty delicate to change. Which you know of course.

> > I am not sure what it's used for. It seems to look for a selector in a
> > class, and report where it's implemented.
> > I suspect that the relevant distinction is that it's built before the
> > install. After the install, apps are built OK. Or maybe it just uses a
> > different makefile than the apps. Either way, the problems we have 
> > with
> > it do not affect the apps.
>
> I'll keep mulling it over.

Sure.

> > > Rambling again, but thanks to your comments I now
> > think this is a build
> > > issue.  We need to change the build process so that
> > __builtin_avcall is
> > > added to libdefobj
>
> > I heartily agree
>
> This is definitely right.  I had a look at the Tru64 build I did 
> awhile back and there is __builtin_avcall in libdefobj.a.

Case closed.

> > >  and also all the dependendent libraries are added
> > into
> > > libswarm.  We only want one library in the install.
> > This may be mauch
> > > easier to with jam (the apple build tool) than make
>
> > Is this necessary? There may be a reason why these libraries are
> > separate. It is clear to me that they are not all always needed, and 
> > so
> > not rolling them in allows for smaller memory footprint at runtime for
> > some applications.
>
> Should make no difference on the Mac with its late binding.  It would 
> clearly be an issue with static builds.

I did say at runtime. If all is in swarm.dylib, and a small swarm app 
loads swarm.dylib, it loads all the library code in the app's process 
memory. Having smaller library units means the unneeded parts never 
make it in the process memory.


> > I am enjoying the discussion in general at this point; we are looking
> > at options and that is good.

> I have to call off for a few days because I have some teching next 
> week.

Heh. And I should write my thesis...

Marc-Antoine



                 ==================================
  Swarm-Support is for discussion of the technical details of the day
  to day usage of Swarm.  For list administration needs (esp.
  [un]subscribing), please send a message to <address@hidden>
  with "help" in the body of the message.