dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Aug 16, 2010 at 02:24:01PM +0100, Garth N. Wells wrote:
> On Mon, 2010-08-16 at 15:20 +0200, Anders Logg wrote:
> > On Mon, Aug 16, 2010 at 02:01:11PM +0100, Garth N. Wells wrote:
> > > On Mon, 2010-08-16 at 14:55 +0200, Anders Logg wrote:
> > > > On Mon, Aug 16, 2010 at 01:37:19PM +0100, Garth N. Wells wrote:
> > > > > On Mon, 2010-08-16 at 14:25 +0200, Anders Logg wrote:
> > > > > > On Mon, Aug 16, 2010 at 01:09:04PM +0100, Garth N. Wells wrote:
> > > > > > > On Mon, 2010-08-16 at 13:58 +0200, Anders Logg wrote:
> > > > > > > > On Mon, Aug 16, 2010 at 12:52:34PM +0100, Garth N. Wells wrote:
> > > > > > > > > On Mon, 2010-08-16 at 13:48 +0200, Anders Logg wrote:
> > > > > > > > > > On Mon, Aug 16, 2010 at 12:24:11PM +0100, Garth N. Wells wrote:
> > > > > > > > > > > On Mon, 2010-08-16 at 13:10 +0200, Anders Logg wrote:
> > > > > > > > > > > > On Mon, Aug 16, 2010 at 10:52:12AM +0100, Garth N. Wells wrote:
> > > > > > > > > > > > > On Mon, 2010-08-16 at 11:49 +0200, Anders Logg wrote:
> > > > > > > > > > > > > > On Mon, Aug 16, 2010 at 11:12:49AM +0200, Anders Logg wrote:
> > > > > > > > > > > > > > > On Mon, Aug 16, 2010 at 10:11:08AM +0100, Garth N. Wells wrote:
> > > > > > > > > > > > > > > > Could the two files containing a 'main' function in
> > > > > > > > > > > > > > > > demo/ode/harmonic/cpp be merged, or one removed? I have written a script
> > > > > > > > > > > > > > > > to generate CMakeLists.txt for all demos, but it doesn't like having two
> > > > > > > > > > > > > > > > 'main' functions in .cpp files in one directory.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Yes, that should be simple to fix. I'll take a look.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Fixed.
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Now, if you run
> > > > > > > > > > > > >
> > > > > > > > > > > > >   ./scripts/generate_cmake
> > > > > > > > > > > > >
> > > > > > > > > > > > > after installing DOLFIN, then run
> > > > > > > > > > > > >
> > > > > > > > > > > > >   cmake .
> > > > > > > > > > > > >
> > > > > > > > > > > > > in demo/
> > > > > > > > > > > > >
> > > > > > > > > > > > > and then
> > > > > > > > > > > > >
> > > > > > > > > > > > >   make
> > > > > > > > > > > > >
> > > > > > > > > > > > > in demo, all the demos will be built.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Garth
> > > > > > > > > > > >
> > > > > > > > > > > > Doesn't work here. Is there a top-level Makefile missing in demo/?
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Yes, the CMakeFile.txt was missing. I've just added it.
> > > > > > > > > >
> > > > > > > > > > It looks a bit strange:
> > > > > > > > > >
> > > > > > > > > > # Manual list of C++ demo directories
> > > > > > > > > > set(DOLFIN_DEMOS_DIRS
> > > > > > > > > >   /home/garth/code/fenics/dolfin/dolfin-cmake/demo/pde/poisson/cpp
> > > > > > > > > >   #/home/garth/code/fenics/dolfin/dolfin-cmake/demo/pde/elasticity/cpp
> > > > > > > > > >   #/home/garth/code/fenics/dolfin/dolfin-cmake/demo/pde/simple/cpp
> > > > > > > > > >   )
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Try again now.
> > > > > > > >
> > > > > > > > Much better. :-)
> > > > > > > >
> > > > > > >
> > > > > > > It would be helpful to kick around what is the desirable approach to
> > > > > > > building demos (and eventually tests and benchmarks). Do we want it as
> > > > > > > part of the main build process, or a separate operation after DOLFIN has
> > > > > > > been installed?
> > > > > >
> > > > > > I prefer it as a separate step since there's otherwise a risk of
> > > > > > integrating the build for the demos in one big non-transparent build
> > > > > > system which is difficult for users to copy and use as templates.
> > > > > >
> > > > >
> > > > > We'll add the CMakeLists.txt files to each demo dir (for now we can just
> > > > > generate them using generate_cmake until we settle on the format), so
> > > > > users can always compile a single demos, and they can mimic the
> > > > > CMakeLists.txt file. We can also have this for the test dir (which we
> > > > > don't presently have with the SCons-based system, which is a bit
> > > > > annoying).
> > > >
> > > > Should we add both the CMakeLists.txt and Makefiles files? Or do we
> > > > require CMake since that is used to build DOLFIN anyway?
> > > >
> > >
> > > We should add only the CMakeFile. The contents of the Makefile will
> > > depend on the platform.
> > >
> > > All the Makefiles can be generated from the top-level demo dir by
> > >
> > >   cmake .
> >
> > ok.
> >
> > > > There are a few scripts now that need to be run occasionally:
> > > >
> > > >   scripts/compileforms
> > > >   scripts/generate_cmake
> > > >   dolfin/swig/generate.py
> > > >
> > > > It would be good to agree on when these should be run and clean it up
> > > > so that they can all be run using a single script.
> > > >
> > >
> > > They do different things, so I wouldn't want them in one script. They're
> > > helpers for developers, so I don't think that it's a problem with having
> > > a few of them.
> >
> > It might help if we rename them and place them in the same directory:
> >
> >   scripts/generate-formcode
> >   scripts/generate-cmakefiles
> >   scripts/generate-documentation
> >
> > and in addition
> >
> >   scripts/generate-all
> >
> > It would help us remember which files we have to generate what.
> >
> > > > > What I'm getting at is do we want to enable/disable demos from the top
> > > > > level CMake configuration, and build them in the ./build  directory, or
> > > > > have users navigate to ./demos and then run CMake?
> > > >
> > > > I think it should be separate. I think this becomes clear if we
> > > > consider a previous discussion we had about generating the demos from
> > > > the documentation.
> > > >
> > >
> > > Yes, that make the decision easy then.
> > >
> > > Any preference for test and benchmarks? This is less important since
> > > most users won't be exposed to test and benchmarks.
> >
> > Not sure, but one thing that is important is to be able to set flags
> > (like optimization) in a common way for all benchmarks.
> >
>
> If we separate tests, etc, from the DOLFIN lib building, compilation of
> the tests will use the flags on dolfin-config.cmake (which is like the
> CMake version of pkg-config).
>
> Garth

That sounds appropriate. I'm assuming the flags that go in there will
be the same (for example -O2) as for building DOLFIN?

--
Anders

Attachment: signature.asc
Description: Digital signature