[Top][All Lists]

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

gnustep-make: xxx_TOOLS API replaced by xxx_COPY_INTO_DIR API

From: Nicola Pero
Subject: gnustep-make: xxx_TOOLS API replaced by xxx_COPY_INTO_DIR API
Date: Thu, 31 Oct 2002 20:41:51 +0000 (GMT)

Since this change might break some makefiles, I thought I'd make a public
announce with explanation of how to migrate (and why the change is good)
so that the thing is known, and recorded in mailing lists.

I removed the old xxx_TOOLS API for frameworks.

It was a nice feature - but I've finally been able to replace it with
something more universally general.

This also simplifies and standardizes the framework code ... I've been
slowly making the framework code more standard, and the rest of the
project types more 'frameworks' :-)

Say that you had a Vanity.framework framework.  With the old API you could

Vanity_TOOLS = Poverty Beauty

then you could have two subdirectories, Poverty and Beauty, containing
tools; such tools would automatically be compiled and copied into the
framework dir at the end of compilation (and never installed in the
traditional way).

I believe this functionality was added because some Apple stuff has a
similar functionality.

I've finally reached the point that I can now implement something better.
I've added a new API:

 xxx_COPY_INTO_DIR = ../Vanity.framework/Resources

this API is currently implemented only for tools, but the setup is totally
general, and I'll implement it for other project types in next days.

So, with the new API, to do the same as with the old one, you would

Vanity_TOOLS = Poverty Beauty


SUBPROJECT = Poverty Beauty

(and then include aggregate.make).  In practice, you just compile the
tools, after or before the framework (as you wish; you may want to do them
after if they are linked against the framework), at the same level of the
framework or below or anyway you want.

Then, in each tool's GNUmakefile you add

 Poverty_COPY_INTO_DIR = ../Vanity.framework/Resources

When Poverty is compiled, this will automatically trigger additional code
to copy the tool into that dir, and will automatically disable
installation of the tool.

The main advantages of the new approach is that you can also put tools
into bundles - not only frameworks; or into applications; or into tools'
resource bundles; or - in the future - possibly into libraries' resource

You can also have multiple levels of COPY_INTO_DIR; for example, you copy
a tool into another tool's resource bundle; then copy the second tool into
a framework (in this case, the compilation order does matter).

The new approach can also easily be generalized in another sense: not only
tools can be copied, but also applications, bundles, frameworks, libraries
etc.  I've implemented only tools for now, but it's very easy to finish
the work and implement other stuff as well.  So we should soon finally
getting to the point that you can bundle everything inside everything,
with arbitrary nesting.

Finally, this change allowed me to clean up a lot more of the gnustep-make
internals.  What we'd really like to get to is frameworks being normal
project types, and the standard execution path inside gnustep-make
providing enough options to support all framework needs as a normal
project type.  This should not be very far at the moment.

reply via email to

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