on 3/24/01 12:27 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
> So, how about it? It there any hope of adopting a common set of project
> definitions, independent of the "engine" that drives the process?
>
> - Sam Ruby
Sam,
Am I not allowed to experiment? In other words, the work that I am doing is
purely experimental at this point and that is why it is called a [proposal].
What I'm trying to do is figure out the best combination of shell script
code I need in order to get the job done (as well as what variables I will
need to define or have defined). I imagine that at some point these shell
scripts and data definitions that I am creating by hand will be auto
generated from a single source. But, until I have an understanding of what
needs to be generated, I certainly can't agree on an overall data definition
format.
I have gone through several iterations of my scripts in just the last few
hours.
For example, what I am doing is generalizing the code into a set of function
calls that get executed to perform several tasks. In my first round of code
and scripts, I figured that I would have two scripts for every project. One
would be responsible for doing nightly src checkouts and the other would be
responsible for doing nightly builds. This was all fine and dandy until I
realized that the way that I wrote the script, I would need to do two CVS
checkouts. Not good because this would increase the amount of time things
take.
Another example is realizing the way that the current directory structure is
setup on disk. This is a key example of how I need to figure out what the
data definition format it. For example, you have two projects:
/home/cvs/jakarta-avalon
/home/cvs/jakarta-avalon-logkit
Now, when we do a nightly src checkout, based on what existing projects are
setup like, I don't think that we want to create (and put the files into
this directory structure):
/www/jakarta.aapche.org/builds/jakarta-avalon/nightly/src
/www/jakarta.aapche.org/builds/jakarta-avalon-logkit/nightly/src
Instead, we want to create:
/www/jakarta.aapche.org/builds/jakarta-avalon/nightly/src/jakarta-avalon-log
kit-20010324.tar.gz
/www/jakarta.aapche.org/builds/jakarta-avalon/nightly/src/jakarta-avalon-200
10324.tar.gz
Making that change requires that the jakarta-avalon-logkit understand that
its output directory should really be into the jakarta-avalon project.
Again, this is a change to the data definition format that I am using.
Now, if I spend all my time trying to fit into your existing project, I
wouldn't get anywhere quickly with my experimentation because I would be
running into the learning curve of working with Gump instead of the learning
curve of creating nightly source and build scripts.
This is similar in concept to what Scott was doing with his code as well. I
can see why he went out and did a bunch of work and then came back and
showed what he did off...only to have you (who is the expert in Gump)
migrate the good parts of what he did into your code.
What I want from you at this point is to show/tell me how I can integrate
what I have been working on for the last few hours into something that is
managed by Gump. I myself will feel much more confident that I can answer
the questions that need to be answered about the different types of goals I
need to achieve given the overall design goals of the build system.
thanks,
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
