[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

make-system for frameworks

From: David Ayers
Subject: make-system for frameworks
Date: Fri, 25 Oct 2002 10:50:46 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016

Hi Nicola,

I'm not sure if you followed my GSWeb posts, but I'm working on building two seperate frameworks (well actually since GSWeb consists of three aggregated frameworks, it's really 6 seperate frameworks) with thier own unique namespaces from one source tree (project). I've already got something working with

make gswnames=(wo/gsw) [target]

My version currently builds the seperate frameworks with clean namespaces in the class hierarchy. The default is currently gsw but the defaults should be settable during configure in the future. Acutally without configure options I would like both sets to be build in the future. But to reallly get that working, I still need to resolve some issues:

1. I need something like $(GNUSTEP_INSTANCE)_ADDITIONAL_CPPFLAGS. This might already exist, but I have just started looking for it. 2. I need some way of making the objects in derived_src $(GNUSTEP_INSTANCE)-dependant,. i.e. if I compile GSWFile.m to GSWFile.o for GSWeb, I don't want that GSWFile.o to be used when I compile GSWeb_wo.
3. I would like to have support for multiple FRAMEWORK_NAME entries.

Currently I'm using ifeq ($(wonames), wo) for 1. and 3. but it would be nice to just compile both as default and allow configure to select only one. This also precludes solving 2. as currently I need to 'clean' between compiling with different gswnames.

I'm not so sure about the implications of 2. It is something I need in this very special case of compiling different executables from the same source. I'm wondering if a project contained multiple tools using the same FunctionsOrCategoriesFile.m should use the same FunctionsOrCategoriesFile.o or whether each should build it's own. But then again this is a similarly construed example. The question is, is it intentional that when compiling multiple tools, that each tool has access to the same pool of .o files?

I'm also "testing" using Instance/Shared/headers.make for Instance/framework.make. Is there any particular reason why this isn't included? Is it just because framework.make simply doesn't reference anything supplied by Shared/headers.make yet?

I'll be looking into all of these issues. If you can give me a pointer as to which documentation would be most helpful or which make files I should use as templates or just give me some helpful comments, I would very much appreciate it.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]