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

Thu Dec 18 10:52:41 PST 2008

Hi Christopher and Matt,

I thought I would chime in:
> 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.
>
>   
For Kepler 1.0, we download a jar rather than source because 1.) it is a 
faster download and 2.) compiling is much faster. The jar file that you 
download actually contains the source and already compiled class files 
for both Kepler 1.0 and Ptolemy within their own jars. Any IDE should be 
able to read this source if you are interested.

For Kepler trunk, in contrast, you download the modules that constitute 
the base system (common, core, util, actors, and directors) but probably 
soon some additional modules soon as well as Ptolemy just as they are 
found in the repository. The download takes a little longer as does 
compilation since you need to compile both the base system and ptolemy, 
whereas when working with 1.0 these are precompiled.
>> 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.
>   
We can make a build file that calls that build.xml in the build-area 
subdirectory. The reason this is like this is because Eclipse does not 
allow for nested projects. The modules need to be in their own projects 
because otherwise you have name clashes that confuse Eclipse due to 
overrides. Basically, if you want Eclipse to be able to see the 
build.xml file and associated files, they need to be peers to the 
modules, rather than one level higher.
>> 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.
>   
I am going to add a command that will query the repository and tell you 
what the other possibilities are for change-to. But the answer is any 
module that contains a modules.txt in a module-info directory is a 
candidate for the change-to command.
>> 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?
>   
Sure. But you have to keep in mind that you are working with a differing 
set of modules as specified in modules.txt.

>   
>> 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
>>
>>     
>
>
>
>   