Re: ctool_OBJC_FILES

[Lyndon Tremblay]

On 2003-05-20 17:35:56 -0600 Nicola Pero <nicola@brainstorm.co.uk> wrote:

> > > If you want to create standalone (ie, without -base) ObjC tools, objc.make
> > > is your friend :-)  You can try
> > > > include $(GNUSTEP_MAKEFILES)/common.make
> > > > OBJC_PROGRAM_NAME = Nicola
> > > Nicola_OBJC_FILES = main.m
> > > > include $(GNUSTEP_MAKEFILES)/objc.make
> > > > ctool.make is for C tools, so it makes somewhat sense that it does not
> > > support OBJC files.
> > > >
> > Yeah, I knew it was a hack (:. So what about libraries? Should clibrary.make 
> > be changed to not support OBJC_FILES as ctool.make? Then, should 
> > objclibrary.make be added as well in if this is the case?
>
> Yes ... in theory that is what might/should be done.
>
> Or maybe it would be much better having a flag (for both tools and
> libraries) which would turn off compiling/linking against gnustep-base.
>
> Need to think.

Flags are probably the best route. I think when GCC supports -Frameworks, 
those are possible with plain objc, so using standard make project targets is 
convinient.

> In practice, you are probably Ok for now with using clibrary.make - that
> will not change anytime soon.  :-)

When clibrary.make generates the library, it uses debug and profile flags, so 
i end up with 'libPromise_d...'. Is there a formal way to depend upon a 
generic library name? '.._LIBRARIES_DEPEND_UPON = -lName', is only used by 
*library.make it seems.