[kepler-dev] Re: [SDM-SPA] RFC new directory structure

[Matt Jones]

Christopher Hylands Brooks wrote:
> I like the CVS structure you propose below.
> 
[snip]
> * With regard to dlls etc., if there are dlls, then there are probably
> lib*.so files for Linux etc.  In Ptolemy classic, each platform
> had a lib.$PTARCH and bin.$PTARCH directory for platform dependent
> variables.   PTARCH was usually set to a platform, such as sol2.8, or
> linux, but could also be set to include a specific platform and or
> debugging level (sol2.8.cfront.debug).  This allows the developer to
> use multiple compilers and debugging levels.
> 
> I'm not sure if this would applies to your situation.  Ptolemy II
> does not use this system (it probably should).
> 
> I'm slightly opposed to a directory called dll, if only because there
> is probably a need for a place for shared libraries under Linux or
> Solaris as well.  I would rather see the directory called w32.
> I don't feel strongly about this, it is just a slight preference.
Yeah, I think you're right about the dll directory name.  We need to 
discuss and agree on a general scheme for native code.  The GARP actor 
that Chad added depends on compiling a C++ model that is accessed via 
JNI in an actor.  Compiling that C++ code can be a pain, although is 
worked out on Windows and Linux.  The resulting dll and *.so files were 
checked in to make it easier for someone without the proper C++ 
compilers on Windows to use that actor.  Chad -- can you outline your 
strategy for where to put c++ code and libs and how it fits into the 
build process?

> 
> * Another issue is that Ptolemy II has a vendors/ directory that
> contains software from other vendors that we are not shipping, but
> portions of Ptolemy II rely on it.  Often the configure script will
> look in vendors/ for optional packages and if the code is not found,
> print a message about where to get the software and where to install
> it.
> 
> Having a vendors/ directory might eventually be useful.
> 
> * I prefer to see the tests adjacent to the code that is tested.
>   - It makes it easier for the developer to run unit tests, in
>   Ptolemy, the developer can run 'make test' in many directories
>   and something useful will happen.
>   - If only a portion of a project is shipped, it is easier to include
>   the tests.  This is especially true if a end user decides that they
>   only want to use a few directories in a project of their own.
>   If the tests are adjacent or under the code, they are more likely
>   to copy the tests.
I can see the argument for this.  We currently have tests as a separate 
  (but parallel in structure) tree.  This allows us to easily build the 
system without worrying about the tests.

> 
> * How are nightly builds and tests handled right now?  Forgive my
> ignorance on this, it might be apparent from the code, I just have
> not looked.
We don't have a nightly build.  We should get one :)  I know your 
existing makefile permits this.  Somtime I would like to discuss the 
Makefile with you and try to figure out why it builds so much more 
slowly than the ant build that I wrote.  Then it would make more sense 
to use it directly for the nightly build.

Matt

> 
> -Christopher

-- 
-------------------------------------------------------------------
Matt Jones                                     jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
University of California Santa Barbara
Interested in ecological informatics? http://www.ecoinformatics.org
-------------------------------------------------------------------