[kepler-dev] RFC new directory structure
Christopher Hylands Brooks
cxh at eecs.berkeley.edu
Thu Mar 18 11:11:36 PST 2004
I'm a fence sitter on this one.
Pros of separate build directories
----------------------------------
The advantages of having a separate build directory for .java files
is that you can use a different compiler (not done that often)
In theory, Java is write once, test everywhere.
Having a separate build directory for .cpp files is much more common
so that multiple architectures, compilers and optimizers can be used.
Multiple users can share source on a read only media (not done that
often)
There are others. . .
Pros of building in the source directory
----------------------------------------
In Ptolemy, we have atomic actors defined in Java, and composite
actors defined in xml. In many ways, atomic and composite actors
should be treated exactly the same, so it makes sense to have them
adjacent.
I frequently remove portions of my tree and check it out with CVS
again to make sure I've not messed up. I would need to
also delete the separate build directory.
In Ptolemy, we consider the source code to be part of the final
release. Our source code is a publication (a thing of beauty (har)),
and we should be proud of it.
I consider a src/ directory to contain things that can be deleted
after the build and install is done. There are other interepretations
of course . . .
In Ptolemy classic, I got really tired of jumping back and forth
between the src and obj.$PTARCH directory.
(BTW - Where will simple user demos go in the layout)
One advantage of having a package of similar files in one directory is
that it makes it much easier to move it around, or delete it, or ship
just a subset.
If I'm not going to ship ptII/actor/lib/security/, I know that the
tests, demos, xml files are all under that directory.
There are other places I need to modify, but those places are
files that refer to ptII/actors/lib/security, not files that
are part of the security package.
BTW - I'm really enjoying this discussion!
-Christopher
--------
OK, but then the "look inside" mechanism probably needs to be adjusted
to find the source code... Perhaps you've done this already?
Edward
At 08:50 AM 3/18/2004 -0900, Matt Jones wrote:
>Here I disagree. One of the most confusing things about the ptolemy tree
>is that the source is spread out over many directories in the root. It is
>so non-traditional that it makes it much less approachable to a new
>developer than the typical method of putting all source code in a src
>directory. The .class files do go in a separate tree (they build into the
>"build" directory, and xml files and the like currently go into lib,
>although that is under discussion. Currently (AFAIK) the only things in
>the src tree are *.java and *.cpp files. I think we should keep this
>structure.
>
>Matt
>
>Edward A Lee wrote:
>>We have avoided having a directory called "src" because in Unix
>>culture such directories are optional. I.e., you don't need them
>>to run the software. If you have a "src" tree, then there
>>should be a separate tree for .class and .xml files, which is a
>>hassle. If you are releasing open source, there really isn't
>>any reason (that I see) to do this...
>>Edward
>>At 03:20 PM 3/17/2004 -0800, Xiaowen Xin wrote:
>>
>>>Hi,
>>>
>>>David, Ilkay, Zhengang, Dan and I have discussed on the phone and over
>>>email the last couple of days about the directory hierarchy
>>>reorganization and have come to a rough consensus. This will be a long
>>>email, so please bear with me =)
>>>
>>>The problem basically is that there is currently no clear organization
>>>of the files in the CVS repository. Workflows are scattered around the
>>>lib/ directory for example, and it's not clear, looking at the
>>>repository, which files relate to SPA and which to one of the other
>>>projects.
>>>
>>>Here's a pictorial view of how we would like to reorganize the
>>>repository. I will be talking mostly about SPA, but the concepts should
>>>carry over to the other Kepler projects as well.
>>>
>>>- copyright.txt
>>>- README
>>>- build.xml
>>>- bin
>>> - runVergil.bat
>>> - runVergil.sh
>>>- build (directory used for compiling the sources)
>>>- docs
>>>- lib
>>> - jar (directory for all the jars)
>>> - dll (directory for all the dlls)
>>>- src
>>> - org
>>> - ecoinformatics
>>> - geon
>>> - sdm
>>> - spa (directory for all the spa-related actors
)
>>> - util
>>>- test
>>>- workflows
>>> - spa (directory for spa workflows)
>>> - seek
>>> - geon
>>>
>>>
>>>So all the SPA related actors will be in the org.sdm.spa package.
>>>Currently there are some SPA actors in edu.ncsu.sdm, but this doesn't
>>>make much conceptual sense. There's no reason to divide up SPA source
>>>files according to the organization that developed it, since all of SPA
>>>will be working closely together to create _one_ set of interrelated
>>>actors. Zhengang will work on moving the actors from edu.ncsu.sdm to
>>>org.sdm.spa. It's better to divide up the source files by project
>>>rather than by organization because the boundary between organizations
>>>is artificial and only serves to confuse things.
>>>
>>>Currently, there's a util/ directory in src/. This isn't really
>>>consistent with our naming convention so far (i.e. putting source files
>>>in packages that reflect which project made them). The argument for
>>>having a util/ directory has been that we'd like to put useful classes
>>>in there that can be shared between the projects. However, this
>>>argument doesn't make much sense because theoretically, all of our
>>>actors could be shared between the projects. So we'd like to move the
>>>files in util/ to org/sdm/spa/util. If another project requires the
>>>functionality of those two classes, then it would have to include the
>>>org.sdm.spa.util package instead of simply the util package.
>>>
>>>After making these changes, all the SPA source files will be in
>>>org/sdm/spa, thus making it much easier to distinguish SPA and its
>>>contribution to Kepler.
>>>
>>>Currently, all the workflows are in lib/ and there are some that are not
>>>in CVS at all. We would like create a top-level workflows/ directory to
>>>store all of the workflows. spa, seek, and geon would be subdirectories
>>>under there. Thus all SPA workflows will be put in workflows/spa/.
>>>Similarly, GEON and SEEK should probably do the same with their
>>>workflows.
>>>
>>>With this directory structure, it would be easy to tell which workflows
>>>are designed for which project, but we must also remember to check all
>>>of our workflows into CVS, and update them when/if they break. Having
>>>PIW-full.xml, PIW-full_new_matt.xml, PIW-int-ex0.xml, and
>>>PIW-full_new.xml, as we do right now is just plain confusing!
>>>
>>>Currently the lib/ directory is a mess. It appears to be the garbage
>>>bin, where everything is dumped if the author can't find a better
>>>container for it. So we propose a series of steps to clean this up.
>>>
>>>1. There are two dll's in lib/. There should probably be a subdirectory
>>>called dll/ under lib/ that contains these dll's. The person who put
>>>these there should probably move them ...
>>>
>>>2. demos.htm and ptolemy-index.html should probably be moved out of lib/
>>>and into a more appropriate folder, probably into src/.
>>>
>>>3. Ilkay will dispose of lib/forBerkeley/ and lib/forSB/ folders or move
>>>them into the top-level test/ folder since they contain testing material
>>>and so don't belong in lib/. Whoever's responsible for
>>>lib/ecoPipelines/ should probably do the same because that's testing
>>>material also as I understand it.
>>>
>>>4. Is everyone ok with our deleting makefile and makefile.lib from
>>>lib/? These are also not library files, and we're not using makefiles
>>>any more.
>>>
>>>5. We should move runVergil.bat and runVergil.sh into a top-level bin/
>>>directory.
>>>
>>>6. Does anyone know what lib/sample.dat and lib/scew-0.3.1.tar.gz are?
>>>Can we delete them?
>>>
>>>7. We will delete the lib/soap directory because it's empty, and there's
>>>already a lib/jar/soap that contains jar files.
>>>
>>>8. We need to do something about lib/testdata/ because it's not a
>>>library file. I personally think it should be moved into the global
>>>test/ directory.
>>>
>>>9. We will move lib/workflow/ into the top-level workflows/ directory.
>>>
>>>The existence of src/exp/ seems a bit questionable. It seems to stand
>>>for "experimental". Maybe it's time to either make it stable and
>>>incorporate it into an existing project, or delete it ...
>>>
>>>Please comment! If nobody objects to the proposed restructuring here, I
>>>can do nothing but assume everybody loves it =) We'd like to get this
>>>finalized as soon as possible, which would make it easier to create a
>>>distribution. Matt will be back next week from travel I believe, and it
>>>would be wonderful to have some kind of rudimentary installer for him.
>>>
>>>Xiaowen
>>>
>>>_______________________________________________
>>>kepler-dev mailing list
>>>kepler-dev at ecoinformatics.org
>>>http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
>>
>>------------
>>Edward A. Lee, Professor
>>518 Cory Hall, UC Berkeley, Berkeley, CA 94720
>>phone: 510-642-0455, fax: 510-642-2739
>>eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
>>_______________________________________________
>>kepler-dev mailing list
>>kepler-dev at ecoinformatics.org
>>http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
>
>--
>-------------------------------------------------------------------
>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
>-------------------------------------------------------------------
------------
Edward A. Lee, Professor
518 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0455, fax: 510-642-2739
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
_______________________________________________
kepler-dev mailing list
kepler-dev at ecoinformatics.org
http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
--------
More information about the Kepler-dev
mailing list