Menu
▾
▴
binarycloud-dev — development list for binarycloud
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
(57) |
May
(287) |
Jun
(166) |
Jul
(286) |
Aug
(273) |
Sep
(254) |
Oct
(144) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Andreas A. <a.a...@th...> - 2001-10-01 18:20:15
|
Hi Peter, >One problem I've found is that build/en/user/conf is not >world-readable/executable after it's built by make. So a default >install results in: Hmm. >etc. This might be intentional -- should those directories be owned by >nobody? I think this is up to the user. The only requirements the files must match is "readabel by webserver" and for the cache directory also writable. If you use nobody/nobody root/root, apache/apache or foo/bar is up to you. Andi |
|
From: Alex B. <en...@tu...> - 2001-10-01 17:51:19
|
hi all, these are fairly complete, and should serve as a guide for most of the remaining Make system tasks. From now on, I'm going to keep the task list small, so people who want to contribute aren't overwhelmed with a massive list to choose from. I've attached everything in a zip. best, _alex |
|
From: Alex B. <en...@tu...> - 2001-10-01 17:27:53
|
> How about this.. You can define the path to your Apache docroot in the > MakeConf, and add a target such as 'make install' to not only build your > tree, but to also install it to your document root. (Could be symlink, > or a copy (??)) I far prefer symlink, because it means we don't have to add any additional complexity to the already complex make system :) _a |
|
From: Jason H. <jc...@ey...> - 2001-10-01 17:00:09
|
How about this.. You can define the path to your Apache docroot in the MakeConf, and add a target such as 'make install' to not only build your tree, but to also install it to your document root. (Could be symlink, or a copy (??)) jason > Anyone see anything I'm missing or that you would like to see added? > I'm nearly done with the Configure system spec, and the new Makefile spec. |
|
From: Alex B. <en...@tu...> - 2001-10-01 16:49:02
|
> One problem I've found is that build/en/user/conf is not > world-readable/executable after it's built by make. So a default > install results in: > > > Warning: Failed opening > '/usr/local/r2/binarycloud/build/en/user/conf/Configuration.php' for > inclusion (include_path='.:/usr/local/php4.mod/lib/php') in > /usr/local/r2/binarycloud/build/en/htdocs/prepend.php on line 44 > > Warning: Failed opening > '/usr/local/r2/binarycloud/build/en/user/conf/Languages.php' for inclusion > (include_path='.:/usr/local/php4.mod/lib/php') in > /usr/local/r2/binarycloud/build/en/htdocs/prepend.php on line 44 > > etc. This might be intentional -- should those directories be owned by > nobody? No, but if you're running as shared installation it's a good idea to keep your source and build trees accessible to a group that has your user and the webserver user. Note that make does not currently modify permissions, I had thought about making that one of the options in MakeConf... we'll see :) best, _alex |
|
From: Alex B. <en...@tu...> - 2001-10-01 16:46:58
|
> Hi Alex, > > the BccModuleCompiler does work now, but only for static module output. But > what about templates containing "load_ordered" output? Static modules won't support load order (at least initially) - the StaticModule() method in page runs the module and sends the output all in one go. I like the 'group' tag, it's a nice alias... but I don't see how we can elegantly support full load-ordered module arrays that are defined in the markup they will be presented in :) _a > I thought of this: > > <bc:module> > <group>content</group> > <index>0</index> > </bc:module> > > short one: > <bc:module group="content" index="0" /> > > Will be transformed to: $Page->output['content'][0] > > or for the whole group: > > <bc:module group="content" /> = $Page->output['content']; > > Andi > > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > https://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
|
From: Alex B. <en...@tu...> - 2001-10-01 16:43:06
|
Based on your last mail, that's pretty much what I was thinking, a 'distro' section of the config file that would tell make what to do :) Have a look at this... I'm going to check it in. _a > Hi Alex, > >> anyone have comments/etc on this make configuration file? >> I'm going to check this in at >> binarycloud/user/bcdev/conf/MakeConf.php.xml > > Opps, I think that answers my the last mail. Sorry, I currently stand a bit > beside me. > > We could add this. If true, additionally a sitename.tar.* file is created > somewhere > > <distribution> > <create>true</create> > <path>BC_PATH.'/make'</path> > <type>tar.gz|tar.bz2</type> > <release>true</release> (if false, timstamp is added to fname) > </distribution> > > Andi > > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > https://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
|
From: Alex B. <en...@tu...> - 2001-10-01 16:34:41
|
> Hi Alex, > > the make stuff looks very fine to me, just one thought: > > >> Make targets for new make system >> --------------------------------- >> binarycloud/ >> all = alias to base, sites, and phpdoc >> clean = rm build dir >> phpdoc = runs make phpdoc in sub dirs >> (site_name) = runs make all in site_name dir >> sites = runs make all in each site dir >> base = runs make all in base dir >> user = alias to sites > > What about adding target: distro (or dist, or distribution, or..). This is > basically make all plus running some extra tools/scripts (i.e. ZendEncoder, > tar/gzip, generating snapshots etc) that can be configured in a file. That's an excellent idea. MakeConf will cover the configuration of that stuff, but I think that's great. I'll add it to the spec and push those to CVS (and to the list) today. best, _alex |
|
From: peter m. <pm...@sp...> - 2001-10-01 15:47:25
|
One problem I've found is that build/en/user/conf is not world-readable/executable after it's built by make. So a default install results in: Warning: Failed opening '/usr/local/r2/binarycloud/build/en/user/conf/Configuration.php' for inclusion (include_path='.:/usr/local/php4.mod/lib/php') in /usr/local/r2/binarycloud/build/en/htdocs/prepend.php on line 44 Warning: Failed opening '/usr/local/r2/binarycloud/build/en/user/conf/Languages.php' for inclusion (include_path='.:/usr/local/php4.mod/lib/php') in /usr/local/r2/binarycloud/build/en/htdocs/prepend.php on line 44 etc. This might be intentional -- should those directories be owned by nobody? Peter |
|
From: Andreas A. <a.a...@th...> - 2001-10-01 11:21:33
|
Hi Salva, >Yesterday I did a complete download of binarycloud from CVS. >So far, >I've only found two problems. >The first one is in $BCHOME/base/core/Makefile. Request.php is missing >from PACKAGEDFILES, so the make doesn't copy it to the build directory. It is still missing? Hmm... >The second one is in QueryManager.php. In _ProcessResult() method, >MetabaseGetColumnNames is called with wrong parameters. >MetabaseGetColumnNames expects three parameters but only two are >supplied. I've changed this: Uaahhh, *sigh*, bad, damend s**t. Ok, I've crushed this bug. Thanks for reporting. Andi |
|
From: IFEROE <IF...@te...> - 2001-10-01 10:53:18
|
Hi, Yesterday I did a complete download of binarycloud from CVS. So far, I've only found two problems. The first one is in $BCHOME/base/core/Makefile. Request.php is missing from PACKAGEDFILES, so the make doesn't copy it to the build directory. The second one is in QueryManager.php. In _ProcessResult() method, MetabaseGetColumnNames is called with wrong parameters. MetabaseGetColumnNames expects three parameters but only two are supplied. I've changed this: $colNames = MetabaseGetColumnNames($this->handle, $_result); for this: $colnames = array(); $ok = MetabaseGetColumnNames($this->handle, $_result, $colnames); and it started to work again. Regards Salva ___________________________________________________________________ Consigue tu e-mail gratuito TERRA.ES Haz clic en http://www.terra.es/correo/ |
|
From: Andreas A. <a.a...@th...> - 2001-10-01 10:07:23
|
Hi Alex, the BccModuleCompiler does work now, but only for static module output. But what about templates containing "load_ordered" output? I thought of this: <bc:module> <group>content</group> <index>0</index> </bc:module> short one: <bc:module group="content" index="0" /> Will be transformed to: $Page->output['content'][0] or for the whole group: <bc:module group="content" /> = $Page->output['content']; Andi |
|
From: Andreas A. <a.a...@th...> - 2001-10-01 09:59:45
|
Hi Andris, >I'm listening.... Sometimes, as it is not very easy to >get to the Internet nowadays. (:<) Hmm. I think I know what you mean. I waited 1 year for my adsl port 'caus they promised to have the infrastructure but they did not. But now: warpspeed, mr. sulu. ;-) >I you still need this [after discussion of SML, etc], I'm >going to think about it. I'd defenetly say "yes" - but not immediatly (even if it would be fine). I think it's good to have this supported. Especially for very short bc:tags like <bc:img id="123" /> where just the id is required. Andi >Andris > >> Hi Andris, >> >> did you or can you modify the XMLUtils to support attributes? I >thought of >> the following: >> >> <tag id="moo" name="HelloWorld" package="hello_world"> >> <child var="value" var2="value2" /> >> </tag> >> >> array( >> 'id' => "moo", >> 'name' => HelloWorld", >> 'package' => "hello_world", >> 'child' => array( >> 'var' => "value", >> 'var2' => "value2", >> ), >> ); >> >> >> This would save lotta work with the Bcc*Compiler classes. > |
|
From: Andreas A. <a.a...@th...> - 2001-10-01 09:50:39
|
Hi Alex, >anyone have comments/etc on this make configuration file? >I'm going to check this in at >binarycloud/user/bcdev/conf/MakeConf.php.xml Opps, I think that answers my the last mail. Sorry, I currently stand a bit beside me. We could add this. If true, additionally a sitename.tar.* file is created somewhere <distribution> <create>true</create> <path>BC_PATH.'/make'</path> <type>tar.gz|tar.bz2</type> <release>true</release> (if false, timstamp is added to fname) </distribution> Andi |
|
From: Andreas A. <a.a...@th...> - 2001-10-01 09:41:09
|
Hi Alex, the make stuff looks very fine to me, just one thought: >Make targets for new make system >--------------------------------- >binarycloud/ > all = alias to base, sites, and phpdoc > clean = rm build dir > phpdoc = runs make phpdoc in sub dirs > (site_name) = runs make all in site_name dir > sites = runs make all in each site dir > base = runs make all in base dir > user = alias to sites What about adding target: distro (or dist, or distribution, or..). This is basically make all plus running some extra tools/scripts (i.e. ZendEncoder, tar/gzip, generating snapshots etc) that can be configured in a file. Andi |
|
From: Andris S. <an...@do...> - 2001-09-30 11:20:01
|
Hello Andi, I'm listening.... Sometimes, as it is not very easy to get to the Internet nowadays. (:<) I you still need this [after discussion of SML, etc], I'm going to think about it. Andris > Hi Andris, > > did you or can you modify the XMLUtils to support attributes? I thought of > the following: > > <tag id="moo" name="HelloWorld" package="hello_world"> > <child var="value" var2="value2" /> > </tag> > > array( > 'id' => "moo", > 'name' => HelloWorld", > 'package' => "hello_world", > 'child' => array( > 'var' => "value", > 'var2' => "value2", > ), > ); > > > This would save lotta work with the Bcc*Compiler classes. > > Andi |
|
From: Alex B. <en...@tu...> - 2001-09-29 00:33:04
|
hey all,
anyone have comments/etc on this make configuration file?
I'm going to check this in at binarycloud/user/bcdev/conf/MakeConf.php.xml
-------
-alex
<?xml version="1.0" ?>
<!--
// {{{ Header
-File $Id: header.ml,v 1.1 2001/06/21 05:00:45 alex Exp $
-License LGPL (http://www.gnu.org/copyleft/lesser.html)
-Copyright 2001, The Turing Studio, Inc.
-Author alex black, en...@tu...
// }}}
-->
<makeconf>
<!-- This is a freetext site name -->
<site_name>Freetext Site Name</site_name>
<!-- use zend encoder to encode all php files in build -->
<encode>
<command>/path/to/encoder -flag</command>
</encode>
<!-- strip comments from code -->
<strip_comments>true</strip_comments>
<!-- auto run phpdoc on each file if the make target is 'all' -->
<autodoc>true</autodoc>
<core>
<!-- use shared binarycloud core? -->
<use_shared>true</use_shared>
<!-- if so, where should the symlink point to? -->
<path>/path/to/somewhere/</path>
</core>
<!--
during make, compare this site source tree with the
default site source tree, and add any missing files to
the build directory
-->
<use_default>true</use_default>
<!-- as per http://www.w3.org/International/O-charset-lang.html -->
<!--
this allows a developer to _develop_ a source tree that is
intended fr multi-language makes, but only make one language
during development. this is convenient if you are making lots of logic
changes that don't require you to see/make all of the languages you have
in Languages.php.xml
-->
<make_force_lang>en</make_force_lang>
<!--
Parse source files with bcc to search for binarycloud and other custom
tags?
-->
<use_bcc>true</use_bcc>
</makeconf>
|
|
From: Alex B. <en...@tu...> - 2001-09-28 21:25:09
|
hi all,
Anyone see anything I'm missing or that you would like to see added?
I'm nearly done with the Configure system spec, and the new Makefile spec.
This is _extremely_ important stuff, please read it carefully and put some
thought into it... I think we'd all like to have a final-ish make system so
we can move on to managers and builders :)
As you can see below, the idea is make the Configure system as simple as
possible... and there wouldn't need to be more than 5 makefile templates.
_alex
Make targets for new make system
---------------------------------
binarycloud/
all = alias to base, sites, and phpdoc
clean = rm build dir
phpdoc = runs make phpdoc in sub dirs
(site_name) = runs make all in site_name dir
sites = runs make all in each site dir
base = runs make all in base dir
user = alias to sites
Makefiles should be generated in all subdirectories of the source tree,
minus some exclusions at bottom.
For each directory that contains only a makefile and other directories,
these targets:
all = runs make all in all sub dirs
clean = removes current dir from all build trees
phpdoc = runs make phpdoc in all sub dirs
(dir_name) = runs make all in dir_name
*the list of dirs is generated by Configure
For each directory that contains a mix of files and directories:
all = runs make all in all sub dirs, and 'files'
clean = removes current dir from all build trees
files = runs InstallCode.php and BCC.php on all files in this dir.
phpdoc = runs make phpdoc in all sub dirs, and phpdoc on files list
(dir_name) = runs make all in dir_name
*the list of dirs is generated by Configure
(file_name) = runs InstallCode.php and BCC.php on file_name.
*the list of files is generated by Configure
For each directory that contains only files:
all = runs InstallCode.php and BCC.php on all files in this dir.
clean = removes this dir from all build trees
phpdoc = runs phpdoc on all files in this dir
For each directory that contains only files under resources/images/:
all = runs InstallImg.php on all files in the dir
clean = removes this dir from all build trees
Exclusions
---------------------------------
binarycloud/base/utils/
(This may be used is it should not really be part of the source tree.
It might be moved to binarycloud/utils/ or binarycloud/make/.)
binarycloud/docs/
|
|
From: Alex B. <en...@tu...> - 2001-09-28 00:59:52
|
> > Well yes, but the heart of the problem is that $BUILD_DIR is now a > relative variable. > This becomes a serious pain as binarycloud/base/Makefile, etc has no > idea which site and language you are wanted to build to. Ah, now I see the point. For example: You've made a modification to some core class and want to propagate that change throughout all your sites. You can assume that you should go through all sites and make for each one... so I think determining the set of sites and their languages should be a function of the top-level makefile. (or, much better, of a ./Configure script which _generates_ the top level Makefile.in) _alex > I've gotten this (what I've got so far) to work, though I'm not too > happy with it. It just all seems too pasty. (aka not creamy enough) > > jason > > > alex black wrote: >> >>> Ugh. This isn't going to be fun. >>> >>> Here's an example hurdle I just tripped over. >>> >>> >>> binarycloud/Makefile >>> - runs base/Makefile >>> - which installs packages into the build directory. $BUILD_DIR. >>> >>> >>> The build directory may be binarycloud/build/site_name8373/en/ >> >> Right. >> >>> Currently, my Makefile.in sees $BUILD_DIR as >>> $(BC_DIR)/build/$(BC_SITE)/$(BC_LANG) >>> >>> So if you run 'make' from binarycloud/, somehow it's supposed to know >>> which site and language you want to install to. >> >> Yes, you will need to parse the Languages.xml file in >> user/site_name/conf/Languages.xml and loop through the array of languages >> building the code for each language. >> >> Of course that will require you to use a php command line script, and not >> default makefile capabilities... > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > https://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
|
From: jason <ja...@gr...> - 2001-09-28 00:44:56
|
Well yes, but the heart of the problem is that $BUILD_DIR is now a relative variable. This becomes a serious pain as binarycloud/base/Makefile, etc has no idea which site and language you are wanted to build to. I've gotten this (what I've got so far) to work, though I'm not too happy with it. It just all seems too pasty. (aka not creamy enough) jason alex black wrote: > > > Ugh. This isn't going to be fun. > > > > Here's an example hurdle I just tripped over. > > > > > > binarycloud/Makefile > > - runs base/Makefile > > - which installs packages into the build directory. $BUILD_DIR. > > > > > > The build directory may be binarycloud/build/site_name8373/en/ > > Right. > > > Currently, my Makefile.in sees $BUILD_DIR as > > $(BC_DIR)/build/$(BC_SITE)/$(BC_LANG) > > > > So if you run 'make' from binarycloud/, somehow it's supposed to know > > which site and language you want to install to. > > Yes, you will need to parse the Languages.xml file in > user/site_name/conf/Languages.xml and loop through the array of languages > building the code for each language. > > Of course that will require you to use a php command line script, and not > default makefile capabilities... |
|
From: Alex B. <en...@tu...> - 2001-09-28 00:20:11
|
> I've checked out a copy of the phpdoc (php-documentation) tree and will go > over it to see how much of a pain in the a** this would all be :) This is a massive bastard of a tree :) it requires that you have fo and saxon or xalan installed, and there's about 10,000 files in here (ok slight exaggeration). I imagine the setup is probably a little nightmarish. I could get this all working, and in some organized, relatively simple & easy to modify format... but it would still be a severe pain in the a** to change the documentation as compared to html documents. Unless there's a cool docbook editor for linux? :) _a |
|
From: Alex B. <en...@tu...> - 2001-09-27 23:44:27
|
hi all,
Anyone out there using a working docbook/xml setup?
If so, any headaches?
I'm looking at this stuff and while it is xml and cool, it's _really_
monolithic, and there don't appear to be any editors that understand it.
I would prefer not to have to write all documentation in DocBook by hand...
given that 90% of people want to view html and I can (don't spit) use a
visual editor for editing the docs to speed everything up.
In general, I want opinions:
-How do you like your docs
-Given that PHPDoc is generating both html and xml (though I've never
seen the PHPDoc xml), it it ok to say: "all documentation is html"
-Does anyone crave PDF? (Docbook of course makes this possible, if
elegant.. assuming you can get through the nightmare of setting it all up.
I've checked out a copy of the phpdoc (php-documentation) tree and will go
over it to see how much of a pain in the a** this would all be :)
best,
-alex
|
|
From: alex b. <en...@tu...> - 2001-09-27 18:32:58
|
> Ugh. This isn't going to be fun. > > Here's an example hurdle I just tripped over. > > > binarycloud/Makefile > - runs base/Makefile > - which installs packages into the build directory. $BUILD_DIR. > > > The build directory may be binarycloud/build/site_name8373/en/ Right. > Currently, my Makefile.in sees $BUILD_DIR as > $(BC_DIR)/build/$(BC_SITE)/$(BC_LANG) > > So if you run 'make' from binarycloud/, somehow it's supposed to know > which site and language you want to install to. Yes, you will need to parse the Languages.xml file in user/site_name/conf/Languages.xml and loop through the array of languages building the code for each language. Of course that will require you to use a php command line script, and not default makefile capabilities... _a |
|
From: Jason H. <jc...@ey...> - 2001-09-27 18:21:41
|
Ugh. This isn't going to be fun. Here's an example hurdle I just tripped over. binarycloud/Makefile - runs base/Makefile - which installs packages into the build directory. $BUILD_DIR. The build directory may be binarycloud/build/site_name8373/it/. Currently, my Makefile.in sees $BUILD_DIR as $(BC_DIR)/build/$(BC_SITE)/$(BC_LANG) So if you run 'make' from binarycloud/, somehow it's supposed to know which site and language you want to install to. This needs a solution. jason |
|
From: alex b. <en...@tu...> - 2001-09-27 17:20:25
|
> Alex, > I'm looking at a re-write for the Makefile system. > > I'd like to have something like this... > > binarycloud/Makefile.in -> things that all makefiles will need Yep. > binarycloud/Makefile -> make base, make ext, make user Yep. > binarycloud/user/Makefile -> makes all site sub-directories / creates > new ones Yep. > binarycloud/user/site_name/Makefile -> makes site_name for every > language defined in site_name/conf/Languages.php.xml Yep. You can use the current user/Makefile as a model, though I'm sure you'll want to make some changes. > This change is most warranted due to the multiple conf/Languages.php.xml > we now have. Everything above is how I expected it to be, I'm glad that we both think it should work the same way :) > This will also allow you to run 'make' from anywhere in your tree and it > will know exactly what to make with what language(s). (with no > environment variable prerequisites other than $BCHOME) Groovy :) _a |
5 messages has been excluded from this view by a project administrator.
