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

[Nicola Pero]

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

No - there are cases in which it might be needed - 

suppose you keep your files in the directory

MyDir/

inside this dir, you have the file

MyDir/myfile

which you want to copy, and the file

MyDir/README

which you do not want to copy.

You then do

xxx_RESOURCE_DIRS = MyDir
xxx_RESOURCE_FILES = MyDir/README

the first one creates MyDir, the second one copies only the file
MyDir/README.

It would be nice to have more control on where/from where you install
files, but it's not there.


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

This has always been so :-)

SUBPROJECTS are really aggregate projects.  xxx_SUBPROJECTS are
subprojects.  They do different things.

Aggregate projects are composed of standalone projects (frameworks,
bundles, applications, etc).  Subprojects are not - they only hold files
which are compiled together, ready to be linked into the main project.

I think I wrote long explanations on the mailing list in the past, so if
my short explanation has confused you please search the archives.

It would be nice to document everything carefully.  It might already
partially be.


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

I don't know about WO 5, but I suppose so.


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

Ok - I agree we should allow non existing resources.

You should get a warning :-) but not an error - that is, you are warned,
but build is succesful (maybe this was not exactly so in all cases before
my recent changes, but now it should be this way).



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

Ok - you could switch to bundle.make as well I suppose ?

Since the makefile 'bundle' code is shared, the same variables should work
with bundles as well.