fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Mar 21, 2013 at 10:14:11PM +0100, Martin Sandve Alnæs wrote:
>   Comments on removal of files:
>   a) Reference data for regression tests can't be removed from the
>   repository. With a significantly larger unit test suite the number of
>   regression tests could safely be reduced, but that is a lot of work. We
>   could strip older versions of reference files and re-add fresh
>   ones.

I agree with this.

>   b) The list contains files like Changelog, CMakeLists.txt from the
>   build system which obviously need to be retained, as well as meshes
>   used by demos.

Did you look at the wrong file? The files suggested for removal are in
the file 'files_to_strip.txt'. The others are used to generated
candidates for that list and I have manually gone through the list to
make the selection. There will likely be some mistakes in that file,
so I would appreciate more eyes looking at it.

And I don't see why we need to keep the meshes. They will be
downloaded and bundled as part of tarballs and distributions. And can
be easily downloaded by users who clone the repository via a simple
script.

>   c) In any event we should keep checked in the few generated files that
>   are part of the dolfin source, so _building_ dolfin does not have
>   dependencies to the entire fenics toolchain.

I see the point but have heard different opinions on this issue. More
opinions? We have a few files currently in dolfin/ale and many more
generated files in the past being part of the library.

>   d) How does the build system know when to/which files to regenerate? I
>   guess calling ffc as part of the building of C++ demos is no worse than
>   the jitting in Python demos. This will add quite a bit to the demo/test
>   build time though.
>   Martin

My suggestion to Johannes was to make it part of calling cmake. Then
it gets built only once, and developers will know where to look for a
script to rebuild them when necessary (inside cmake/scripts).

--
Anders


>   > Nice work!
>   > So this is how git get so fast, we first remove all the large files
>   ;)
>     Yes, exactly.
>     I didn't think it would be such a hassle. I was imagining a simple
>     conversion (which took just a few minutes to figure out), but then
>     suddenly we are in the git camp and need to rewrite our history to
>     present a beatiful repository to the world. :-)
>   repository.
>   repository.



>   > How will this affect the possibility to compile legacy versions of
>   > dolfin to test for example speed ups? Are these done with cached
>   tarballs?
>     Those can be built (with a lot of effort) using the tarballs, and
>     the
>     converted unchanged repository as well as the present bzr repository
>     will be stored for eternity on the web server.
>     What needs to happen now before we can make the transition is:
>     1. Get the buildbot green again. It is broken as a result of some
>     renaming and removing of files that the buildbot needs to generate.
>     2. Release 1.2.
>     3. Get comments from Florian or anyone else interested in merging in
>     converted repos on the Git side.
>     4. Get comments from developers on the list of proposed files to be
>     deleted from the history.
>   found
>   the



>   > Sounds good.
>   > Johan
>   _______________________________________________
>   Mailing list: [3]https://launchpad.net/~fenics
>   Post to     : [4]fenics@xxxxxxxxxxxxxxxxxxx
>   Unsubscribe : [5]https://launchpad.net/~fenics
>   More help   : [6]https://help.launchpad.net/ListHelp
> Referenser
>   1. mailto:logg@xxxxxxxxx
>   2. https://gist.github.com/alogg/5213171
>   3. https://launchpad.net/~fenics
>   4. mailto:fenics@xxxxxxxxxxxxxxxxxxx
>   5. https://launchpad.net/~fenics
>   6. https://help.launchpad.net/ListHelp