Re: Re[2]: Frameworks localized 'components'

[Nicola Pero]

>  >| >  >| May be I'm wrong but it seems that localized (for example: 
> French.lproj/MyComponent.gswc) components are not
>  >| >  >| installed. 
>  >| >  >| I haven't found something in makefile concerning this. Is it 
> possible to add this feature like it's done for
>  >| >  >| LOCALIZED_RESOURCE_FILES ?
>  >| > 
>  >| > I've made a Q&D patch to add xxx_LOCALIZED_COMPONENTS but I'm 
> definitely not a (GNUstep) makefiles expert. Can
>  >| someone
>  >| > integrate it ?
>  >| 
>  >| Thanks - looks nice - I applied it to CVS
> 
> Thank you.
> 
> 
> xxx_LOCALIZED_WEBSERVER_RESOURCE_DIRS 
> and xxx_WEBSERVER_RESOURCE_DIRS documented in
>         Makefiles/Instance/framework.make
> are not used.

I implemented xxx_LOCALIZED_RESOURCE_DIRS and
xxx_WEBSERVER_LOCALIZED_RESOURCE_DIRS.

<xxx_WEBSERVER_RESOURCE_DIRS was already there>.

I also did a major rewriting and cleanup of code there (in
Instance/Shared/bundle.make).

That code is very relevant to gsweb, because once
Instance/Shared/bundle.make supports properly symlinks, then both
gswapp.make and gswbundle.make will switch to use that code too (they
would then share most code with other makefiles, be a lot simpler, and
benefit from improvements to other makefiles immediately with little
maintenance effort).


> Could you add the makefile code to process them ?
> I don't now exactly how they should work. Does someone have an idea ?

Ahm ... well since you are here, let's talk about this :-)

I have been trying to keep the existing options - I didn't want to make
anyone unhappy by removing options :-) - but when I looked/rewrote that
code, it seemed to me that maybe we had a few options too many ... namely
xxx_COMPONENTS and xxx_LOCALIZED_COMPONENTS - and also that a few options
were misnamed - xxx_LOCALIZED_WEBSERVER_RESOURCE_FILES (which should be
xxx_WEBSERVER_LOCALIZED_RESOURCE_FILES) and similar.

I think I managed to keep support for all stuff without dropping anything
(actually, adding a lot of new features), while softly pushing towards
standardization and simplification of options.

Here is a short description of the various options - 

xxx_RESOURCE_FILES: files which are copied into the bundle Resources dir.  
These files are currently recursively copied, which means they could
actually be directories full of other files :-)

xxx_COMPONENTS: directories which are recursively copied into the bundle
Resources dir.  This is somewhat superfluous given that xxx_RESOURCE_FILES
can contain directories, and I've simplified the implementation so that
COMPONENTS and RESOURCE_FILES are merged in a single variable and treated
together (looks like this might also slightly improve performance by
reducing the number of subshells, but I didn't profile/time it).

xxx_RESOURCE_DIRS: directories which are created into the bundle Resources
dir.  This is normally used to create directories, in which then files are
copied (by listing them in xxx_RESOURCE_FILES).

xxx_SUBPROJECTS: this is a still-under-development thing (and has its
wrinkles still).  I assume that in the best implementation, subprojects
can have resources, and when you build the main project, resources from
subprojects are copied into the main project resource bundle.  But this
adds an additional complication to the whole thing, because in the ideal
implementation, subprojects resources are not copied into the main project
resource bundle, but only sym-linked (for build performance - to avoid
copying around potentially huge files with no gain).

Actually, just to make things more clear ... it would make a lot of sense
to support sym-linking all the above files/directories into the project
resource bundle, rather than hard-copying them.  That might/would increase
build speed considerably (which would affect us all, because it would
affect stuff like gui applications).  When you install the project, then
we would pass to tar the appropriate flags to not preserve symlinks, but
to recursively copy them.  We already pass those flags (and have already
managed our little portability nightmare/battle with the flags) so we can
win here. :-)

The main downside is that symlinks are more difficult to port and in some
cases it's a hassle to write the shell code to create them properly (I'm
talking by experience) ... but with the relative_path.sh shell I wrote, it
might be much easier (/possible) (problem it's that it's a very expensive
shell script, in terms of performance, so we must try to use it as little
as possible - better use it never).

Anyway - back to the options - then we have the LOCALIZED variant of all
of the above - obtained simply by inserting 'LOCALIZED_' between xxx_ and
the variable name - for example,

xxx_LOCALIZED_RESOURCE_FILES
xxx_LOCALIZED_COMPONENTS
xxx_LOCALIZED_RESOURCE_DIRS

they behave the same as for xxx_RESOURCE_FILES etc, except they copy
to/from localized dirs.

In practice, this means that the LANGUAGES variables is evaluated.  For
each language listed in that variable (with 'English' being assumed if the
variable is empty), xxx_LOCALIZED_YYY will perform the same as xxx_YYY
from the directory

Language.lproj

into the main resource bundle subdirectory Language.lproj/.

For example, xxx_LOCALIZED_RESOURCE_FILES, if LANGUAGES is 'English
Italian', will copy from the specified files from

English.lproj into {main bundle}/Resources/English.lproj
Italian.lproj into {main bundle}/Resources/Italian.lproj

==

Then, we have the WEBSERVER variants.  All of the above variables should
be still available with WEBSERVER inserted between xxx_ and the variable
name, as in xxx_WEBSERVER_RESOURCE_FILES,
xxx_WEBSERVER_LOCALIZED_RESOURCE_FILES, etc.

<here there is a historical quirk - the actual historical name of that
particular variable is xxx_LOCALIZED_WEBSERVER_RESOURCE_FILES rather than
xxx_WEBSERVER_LOCALIZED_RESOURCE_FILES ... I've added support for the new
naming, while still keeping the old one for backward compatibility.>

They will do the same as the normal variables, except copying from
WebServerResources/ and into the WebServer/ subdir of the resource bundle.

I tend to think gnustep-make should be extremely general purpose, so I've
been thinking in the past maybe we'd like to generalize this, and have
something like a generic xxx_SPECIAL_RESOURCE_FILES which copies from
xxx_SPECIAL_RESOURCE_SOURCE_DIR into the xxx_SPECIAL_RESOURCE_TARGET_DIR
subdir of the resource bundle, and then have the WEBSERVER variables and
their dirs defined/implemented on top of this.  But then what I'd *really*
like at that point is have a whole family of parametrized variables
xxx_zzz_RESOURCE_FILES where you can have 'zzz' to be from a set of values
you define.  'WEBSERVER' would just be a value of this 'zzz'.  This poses
complicated problems because of the multiple lookup and likely would
require an additional submake invocation per zzz to be implemented - so
it's not an option and nobody ever asked for this anyway :-) so it's just
my own phantasy and you can forget about it.


Anyway - sorry for the long email - I hope it gave you a fair summary of
the options and the problems involved.

Build performance is an extremely major issue here.

Main changes which are planned - 

* proper subproject resources support
 <it doesn't work well currently, it's adding unnecessarily subdirs etc>

* using symlinks rather than copying things - possibly this option turned
on/off by a variable

when that's done, using the code in gswapp.make and gswbundle.make, and
simplifying them dramatically by dropping all the custom code there which
does the same.