Re[4]: Frameworks localized 'components'

[Manuel Guesdon]

Hi Nicola,

On Wed, 12 Jun 2002 15:06:18 +0100 (BST) Nicola Pero <address@hidden> wrote:
 >| 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).

I strongly agree !


 >| > 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 :-)

OK.


 >| 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).

OK. It seems logical.



 >| 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).

So, if I understand well, this variable is not necessary (directories in 
xxx_RESOURCE_FILES are recursively copies), is
it ?


 >| 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).

So, projects in xxx_SUBPROJECTS will be different from subprojects in 
SUBPROJECTS.
Now, I usually have a GNUmakefile with only SUBPROJECTS to group  my 
Frameworks, GSWApps,..
So your xxx_SUBPROJECTS variable will allow to have subprojects with resources 
in my Frameworks,... like in WO 5 ?
As I do things manually, it's not really a requirement for me but I don't know 
for people using tools like Project
Center. I cc Philippe for this part


 >| 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. :-)

Sounds good.


 >| 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.

OK. We may remove xxx_LOCALIZED_COMPONENTS as we can did this with 
xxx_LOCALIZED_RESOURCE_FILES as you've writen
previously.


 >| 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

OK. A little note, I think the we should allow non existing resources for some 
languages because we may have some
resources localized only for italien but not for french, for example. This case 
will occur if we need localization of
GNUstepWeb components only for size problems on some languages.


 >| ==
 >| 
 >| 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 haven't verified the actual code but it will be usefull to allow directories 
in this ad for RESOURCES_FILES.
For example, it's nice to organize images or files in subdirectories of web 
server.


 >| 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.

It's a good idea so we'll cover a large set of case but if this is a big source 
of problem, I think we can do without 
except if some other people have some needs for this.



 >| 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.

I'm not sure someone still using gswbundle.make . Personnaly, I've switched to 
frameworks :-)

Thank you !

Manuel
--
______________________________________________________________________
Manuel Guesdon - OXYMIUM <address@hidden>
14 rue Jean-Baptiste Clement  -  93200 Saint-Denis  -  France
Tel: +33 1 4940 0999  -  Fax: +33 1 4940 0998