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

David Welker david.v.welker at gmail.com
Fri Dec 19 08:40:24 PST 2008 

Agreed,

I am going to make it reflect the instructions on the our website shortly.

David
> Hi David,
>
> kepler/modules/build-area/README.txt should probably be updated to
> describe how to build using the current SVN tree instead of building
> from 1.0 sources.  The instructions for building using 1.0 should be
> later in file.  Most users will find it very confusing that the first
> instructions build from 1.0 sources instead of the sources that are
> in the svn repository.
>
> The problem here is that usually when one downloads a svn repository,
> one expects to build from it.  If there was a separate tar download
> that created a kepler-1.0/ directory, the I'd expect to be building
> with Kepler 1.0.
>
>
> _C
>
>
> David Welker wrote:
>> 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
>>>>
>>>>     
>>>
>>>
>>>
>>>   
>>
>

More information about the Kepler-dev mailing list