[kepler-dev] New instructions for building the trunk of Kepler...

[Matt Jones]

Hi Christopher,

Some comments to your email below...

On Thu, Dec 18, 2008 at 7:45 AM, Christopher Brooks
<cxh at eecs.berkeley.edu> wrote:
> Hi David,
> Congrats!  The build system looks pretty good.  Below are
> some suggestions
>
> 1. kepler/INSTALL.txt needs updating.
> 2. kepler/modules/build-area/README.txt says:
>> The latest version of quick instructions on how to build Kepler using >
>> the Extension Build System
>> can be found here:
>>
>>
>> https://dev.kepler-project.org/developers/teams/build/systems/build-system/extension-build-system/view
>>
>>A possibly out-of-date version of this document is reproduced below:
> ...
>
> It would be good to commit to updating the README.txt file instead of
> updating the a webpage.  The primary reason is that people who
> are building might not have web access.
I agree -- it would be best to keep the build instructions up to date
in the SVN checkout.

>
> 3. In kepler/modules/build-area/README.txt, I ran
> ant change-to -Dsuite=vanilla-1.0
> which downloaded a jar file.  It would be nice if this download was
> not required, perhaps if the jar file was checked in or built.
> The primary reason is that if I'm on the plane and want to try out
> Kepler from source, I can't.
I also agree with this.  We'll need to discuss further how this core
trunk module build works while we continue to refactor the core into
more functionally distinct and smaller modules.

>
> 4. There should probably be a top-level kepler/build.xml file that
> runs the basic commands to build and run Kepler.  The reason is
> that users will expect to be able to run ant in the top-level
> directory and have something happen.   The kepler/build.xml
> file need not be too complex, but it should have the basics
> like run, compile and clean
I also would like this.  In every other project the main build file is
at the root of the development tree and can be run immediately after
checkout.  We should be able to achieve the same while maintaining the
whole ability to switch modules.

>
> 5. When I'm in kepler/modules/build-area, if I run "ant" with
> no arguments, I should get back a list of the possible targets.
An alternative would be to have 'ant' run the default trunk build,
while the standard 'ant -projecthelp' gives the list of targets.  I
could go either way on this.

>
> 6. When I'm in kepler/modules/build-area, what are the other
> possibilities for "ant change-to"?
Any of the other defined suites or modules that are in the modules
subdirectory.  That this is confusing is one of the reasons we need
the root level trunk build to be more transparent to developers who
are new to the system.

>
> 7. I want to add targets for running findbugs and the Javadoc
> doccheck.  Where should these go?
Can't they just be added to the build.xml file, either directly or via
an import?

>
> 8.  We really need a nightly Kepler build and a continuous build.
We have the nightly build via NMI.  Its on Chad and David's todo lists
to make this work again with the newly rearranged build.  Currently it
is scheduled to run twice a day.  We could change this to run
continuously, immediately starting a new build after the old one
finishes, and only emailing results if there is an error.  Would that
be helpful?

Matt

>
> Again, these are all just small things and I'm sure that many
> of them are on a todo list somewhere.  Again, congrats on getting
> this going.
>
> _Christopher
>
> David Welker wrote:
>>
>> Hi Matt and everyone:
>>
>> Here is how you would use the build system to build at the trunk (assuming
>> you want to check out the trunk, which will check out all modules except for
>> ptolemy.)
>>
>> svn co https://code.kepler-project.org/code/kepler/trunk kepler
>> cd kepler/modules/build-area
>> ant change-to -Dsuite=vanilla-trunk
>> ant run
>>
>> Here are the same commands, but with some explanation.
>>
>> 1.) svn co https://code.kepler-project.org/code/kepler/trunk kepler
>>
>> This checks out the trunk of kepler including all the modules. Except,
>> this doesn't check out ptolemy. This is a lengthy checkout, so be patient.
>>
>> 2.) cd kepler/modules/build-area
>>
>> You need to change to this directory because this is where the build.xml
>> that runs everything is located.
>>
>> 3.) ant change-to -Dsuite=vanilla-trunk
>>
>> You need to do this to download ptolemy. Note, that temporarily, this will
>> download Ptolemy to the directory ptolemy-trunk. The reason is because there
>> already exists a ptolemy directory that is in use for another purpose.
>>
>> 4.) ant run
>>
>> This will compile the code, build the kar files, and execute Kepler.
>>
>> Hope this helps. As you requested, I am sending this email to kepler-dev
>> as well.
>>
>> Please also note that the checkout is a little larger now than it will be
>> in the future as we make necessary modifications.
>>
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at kepler-project.org
>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>
> --
> Christopher Brooks (cxh at eecs berkeley edu) University of California
> CHESS Executive Director                      US Mail: 337 Cory Hall
> Programmer/Analyst CHESS/Ptolemy/Trust        Berkeley, CA 94720-1774
> ph: 510.643.9841 fax:510.642.2718             (Office: 545Q Cory)
> home: (F-Tu) 707.665.0131 (W-F) 510.655.5480
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matthew B. Jones
Director of Informatics Research and Development
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara
jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
http://www.nceas.ucsb.edu/ecoinfo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~