Andrew wrote: > Relative paths don't really work unless you specify somewhere what they are > relative to (current dir isn't really a good option). For example, relative > paths work in the apache config, because the config root is specified as > /usr/lib/apache2/conf (which is a symlink to /etc/apache2). > > With catalyst, there are so many paths that could be the "root" > (/var/tmp/catalyst, /etc/catalyst, some random dir where you store your > specs, > etc.) that it just doesn't work.
What I am in the process of doing is putting together a pre-configured Catalyst-based LiveCD build environment that is newbie-friendly and housed in a CVS. When a Catalyst newbie checks this build environment out of the CVS, I was hoping to have the Catalyst configuration file and the spec files already pointing to the resources they need to ( which are also present in the checked out environment ). The ability to use relative paths in the Catalyst configuration file and the spec files seems like it would work for this use. I have experimented with placing "print os.getcwd()" in the catalyst2 script and it indicates that the current working directory is set to whatever directory this script is launched from. This is the behavior I am interested in using because, after checking the LiveCD build environment out of the CVS, I would like the user to change into a specific directory which contains short scripts that will allow them to build various targets. I am currently experimenting with removing "expand=0" from the calls to the file_locate function on lines 159 and 162 in generic_stage_target.py to see if this breaks anything. Thanks :-) Ted Kosan [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
