Re: GNUstep framework install question

[Nicola Pero]

> Hi Nicola,
> 
> I've spent part of the weekend porting the ED* frameworks (OSX 
> frameworks) to GNUstep. I was quite surprised to find out how easy it is 
> to write GNUmakefile's ... cool. However, one question arose that I 
> haven't found a solution for, yet.
> 
> The ED* frameworks offer several extensions for AppKit (or gnustep-gui) 
> that will only be built, if the $(GUI_LIB) is not nil. However, 
> EDCommon.framework i.e. sports a common framework header, EDCommon.h. 
> This header contains all #includes, even those that have GUI 
> dependencies. On OS X (and Rhapsody as well) we strip these #includes 
> off after doing the install, with an additional target. I wrote such a 
> target in my GNUmakefile.postamble:
> 
> 
> after-install::
> ifeq "$(GUI_LIB)" "nil"
>          ( \
>                  for ph in $(PATCH_HEADERS); \
>                  do \
>                          
> h_path=$(FRAMEWORK_INSTALL_DIR)/$(FRAMEWORK_VERSION_DIR_
> NAME)/Headers/$$ph; \
>                          $(AWK) '/#ifndef.*GUI_LIB/, /#endif.*GUI_LIB/ 
> { next; } { print $0; }' $$h_path >> $$h_path.fixed; \
>                          $(MV) $$h_path.fixed $$h_path; \
>                  done ; \
>                  $(ECHO) "Fixed for non-GUI build $(PATCH_HEADERS)"; \
>                  )
> endif
> 
> 
> The problem is, that $(FRAMEWORK_INSTALL_DIR) evaluates to "". Is there 
> any way I can find out about the install destination of framework 
> headers in a postamble?

Hmmm.  The problem is a bit technical ... this rule is executed in the
'Master' invocation -- ie, when a GNUmakefile is processed, there is a
Master invocation for each makefile, and then an Instance invocation for
each concrete target to be built.  The Master invocation task is just to
fire the Instance invocations -- it knows nothing about the little details
of each different target to build -- that is the task of each Instance
invocations.  Each Instance invocation builds all the little variables and
details of its own target, and builds it.  This design simplified/es
mantainance.

The original design of gnustep-make is a bit confused in how the
after-install and before-install and similar targets work.  They are
executed in the Master invocation (it can't be in a different way, since
they are not target specific).  Now the problem is that people - as in
your case - do often need to access their target little variables
(installation dirs, object files, custom dirs created by that specific
project type etc) inside these rules ... but these variables are not
available! <You can consider the fact that FRAMEWORK_VERSION_DIR_NAME is
available to you a lucky coincidence (if not a bug or a hack in
gnustep-make) !  That variable is a framework specific variable, and
should normally be set inside the framework specific makefile fragment,
not in the Master code.>

For all targets, gnustep-make is a bit more friendly - for each instance
(eg, EDCommon) there is a

after-EDCommon-all::
        
target which is automatically executed in the Instance invocation, after
all for EDCommon is done.  That will automatically have access to all
EDCommon specific variables, because it is in the Instance invocation for
EDCommon.

Well I think the correct solution would be that gnustep-make recognizes a
new target - (assuming you framework is called EDCommon) - 

after-EDCommon-install::
        ...

that rule would be automatically executed during the Instance invocation,
so you would have access to all the instance variables (any FRAMEWORK_*
variable you like).

For each Instance invocation we perform, we should likely recognize

after-$(GNUSTEP_INSTANCE)-$(OPERATION)::
before-$(GNUSTEP_INSTANCE)-$(OPERATION)::

and execute it before/after the operation.

At least, we could do that for 'all' and 'install'.  The problem with
'clean' and 'distclean' is that often we don't perform the Instance
invocation at all for those operations - which makes them a lot speedier -
but also means we would never execute the user-defined
after-$(GNUSTEP_INSTANCE)-$(OPERATION) [well I can think about
workarounds].

This just to say that ... I'm adding 

before-$(GNUSTEP_INSTANCE)-install
after-$(GNUSTEP_INSTANCE)-install

to *all* gnustep-make project types.

A long email to say ... the solution to your problem is:

 * update from latest gnustep-make CVS where I've added
   after-$(GNUSTEP_INSTANCE)-install targets;

 * rename your after-install to after-YOUR_FRAMEWORK_NAME-install.

 * finally, let me know if it works :-)


If you want to stay with the old gnustep-make, a quick solution likely is
to replace FRAMEWORK_INSTALL_DIR with GNUSTEP_FRAMEWORKS, which should be
defined in the Master invocation.  But the code might break in future
gnustep-make releases if the gnustep-make cleanup goes to the point we can
hide the FRAMEWORK_VERSION_DIR from the Master invocation, as it would be
desiderable.  So - my suggestion is to look at the future and try using
the new gnustep-make support for after-xxx-install. :-)