Re: [swarm-hackers] Old autoconf build process is broken in current trunk

[Bill Northcott]

On 26/11/2009, at 6:30 AM, Scott Christley wrote:
> On Nov 25, 2009, at 3:05 AM, Bill Northcott wrote:
>> In file included from ./Swarm/Collection.h:27,
>>                from ../../../../src/collections/../collections/Array.h:26,
>>                from ../../../../src/collections/Array.m:26:
>> ./Swarm/collections.h:1238:36 ./Swarm/collections.h:1238:36: error: 
>> Swarm/collections_types.h: No such file or directory
>> 
>> 
>> I have no idea how this works for you on Linux.  In my build, the Swarm 
>> symlink in builddir/src/collections goes back to the source, which is why 
>> Swarm/collection_types.h is not found.   <collection_types.h> would work, 
>> but I appreciate that it is not what is wanted.
> 
> With the change I made, it should not be trying to include 
> <Swarm/collections_types.h>, it should be trying to include 
> <collections/collections_types.h>.  Do you have SWARM_OPENSTEP defined for 
> some reason?  Maybe you configured with "--enable-openstep"?

I thought from your previous email that I needed --enable-openstep to use the 
Apple runtime.

I tried without openstep and got:

> libtool: compile:  gcc -B ../../tools -DHAVE_CONFIG_H -I. -I./objc 
> -I../../../libobjc -I../../../libobjc/objc -I../../../libobjc 
> -DBUILDING_LIBOBJC -g -Os -fnested-functions -B ../../../libobjc/../tools 
> -fno-strict-aliasing -Wall -Wno-import -Wno-protocol -Wno-long-long 
> -fno-strict-aliasing -Wall -Wno-import -Wno-protocol -Wno-long-long -MT 
> Protocol.lo -MD -MP -MF .deps/Protocol.Tpo -c ../../../libobjc/Protocol.m  
> -fno-common -DPIC -o .libs/Protocol.o
> ../../../libobjc/Protocol.m:79:0 ../../../libobjc/Protocol.m:79: error: @defs 
> is not supported in new abi
> ../../../libobjc/Protocol.m: In function '-[Protocol 
> descriptionForInstanceMethod:]':

There also seems to be an @defs in List.h.  I have no idea what this is about 
at this point.
Do you know if this code is actually used anymore?  I understand it as a way of 
breaking the encapsulation and grovelling in the data structures, which is not 
nice unless really needed.  Any way, the compiler does not understand it.  I 
suspect this is chopped out by your build.

> The issue with this is then you have to know all of the individual headers in 
> order to create symlinks, or have to make some assumption like link all *.h 
> files.  It's possible but it complicates the matter.

Where is the extra Complication? We always knew that it was hard to write 
Framework compatible code with the <Framework/header.h> style and get it to 
build in a conventional Unix sort of way.
> 
> I'm a little unclear what you are exactly trying to do.  Is it you want to 
> build Swarm with tcl/tk GUI and Apple compiler and Apple runtime?  
> Essentially the same as what I've done but using tcl/tk GUI instead of 
> OpenStep?

I would like to maintain the autoconf build on MacOS X.  A lot of people 
understand that and it is documented.  Xcode is great is great for pure Cocoa 
work, but this is a sort of mixed environment.

>  If that is your goal, then I think the most robust route is to use Xcode, 
> copy the SwarmOSX project, include the TCL/TK framework, and let Xcode handle 
> the compiling and linking.

That is as maybe, but I need to understand what you have done first, and at the 
moment it is very murky.  You said in an earlier email that there was some 
issue with Tcl/Tk.  Maybe that is related to the problems with the autoconf 
build.
> 
> Trying to get the autoconf/libtool/makefile system to do all of that for you 
> means you are going to have to reverse-engineer all the flags and so forth 
> that Xcode uses to compile and link, then figure out how to integrate that 
> into the build system.  Is it possible, sure, by why not go the simpler route.

Xcode is fairly transparent if you look at the full build transcripts.  It is 
not hard to see what it is doing, because there is a full list of all the 
environment variables at the start of the transcript.

Bill

smime.p7s
Description: S/MIME cryptographic signature