[binarycloud-dev] Naming vs. Location

[Alex B. <en...@tu...>]

hi all,

I was writing the big long-winded thing below when I realized the first
option has all the advantages, so decision made (unless someone can make a
_really_good_ counter argument :)

We're going to use special extensions in the source tree to simplify the
structure of the source tree and allow developers to make file types easily
so make and configure can process them appropriately.

I've got a partial spec in the R2Classes.txt file, which I'll re-publish in
a (somewhat) complete form in the next message.

After that I'll put out a spec on the 'make process'

best,

_alex






-------------


Wanted some opinions on the use of filenames (as opposed to locations) to
determine build location (and processing) outside of packages...

For example, If you have a strings file in
user/site_name/lang/StringFile.php.xml, we know that it will be made into
php and put in build/site_name/lang/user/lang/StringFile.php.

That was easy, right? What about a String file that's specific to a module?

Do we allow:
user/mod/hello_world/HelloWorldStrings.lang.xml

and assign meaning to the filename, so we know that
HelloWorldStrings.lang.xml should end up as HelloWorldStrings.lang (a php
file) in build/site_name/lang/user/lang/HelloWorldStrings.lang?

Or do we force users (and installations) to put all langs files in
user/site_name/lang/FileName.php.xml?

There are advantages and disadvantages to both.

The advantages of using filenames:
    -We already use filenames for other purposes (.php.xml, and
.lang_code.ext for language-specific file substitution)
    -It makes the source tree simple, and clean
    -It makes installation and removal of modules clean and easy
    -It forces some standards on file names so we can all at leasy figure
out what the hell is going on :)

The disadvantages to it:
    -It forces us to either 1) add complexity to the makefile system to
allow for the proprocessing of 'special' files required by make like Strings
files and Configs, or 2) Force the user to separately re-make in areas
containing files that make needs in order to see the changes propagate
through the system.

    I prefer the latter by far, because is puts the 'power' into the hands
of the user/developer, not us.

The advantages of fixed file locations:
    Oop, no. Above is better.