Hi. See below. On Sun, Sep 7, 2008 at 9:57 PM, Wolfgang Bangerth wrote: > > - I think it is too complicated to define via a ./configure switch whether > contrib/ libs should be built with debug mode or not. I would much rather > that we *always* build libraries in contrib/ in *both optimized and debug > modes* and then link with the correct ones when necessary. > That would make > your patch significantly simpler, because you can throw away the > conditions. It would of course increase build times, but since the stuff > in contrib/ is relatively little compared to the overall work, I think > that's acceptable. Do you think you could change your patch in this > direction? Yes, I agree. Function parser is less than 3MB. I will change it in nearly two weeks, I am simply not near any good computer (more precisely: OS) most of the time :)
The thought was that additional, bigger contrib libraries may be swallowed by the DEAL.II in the future, in which case it could make sense to save disk space (not for private computers, but mainly for people who work on servers and install DEAL.II in their user directory). But let's address the problems as they appear. > > - I've already applied the patches to base/source/parsed_function.cc and > aclocal.m4; you'll get them simply by making an 'svn update'. aclocal.m4 - I see it. base/source/parsed_function.cc - did I do any changes there ? I can't check right now :) >> I have some plans to simplify the build system of DEAL.II and also >> make it perform better and more user friendly (no annoying >> messages of subdirectory travelling in case of small changes). >> I plan to do it by putting end to its recursive structure, using >> techniques described in >> http://miller.emu.id.au/pmiller/books/rmch/ >> but this is a long project... (Nevertheless I did it in all >> my projects and pretty confident in it) Any opinions ? > > This is a big project indeed. I have some reservations in that the current > system may not be optimal, but it actually works fairly well. Furthermore, > even for the case where only 2 or 3 files have to be re-compiled, it's > usually the time to run the compiler, not make, that takes long. So I'm > not quite sure what problem your approach is solving. On the other hand, I > find the smallness of the current Makefiles a good thing. > > I'm not opposed to you working on this aspect (in fact I think it would be > great if you did) but I'd recommend that we talk about individual ideas > before you go spend a lot of time on them! Yes. (But actually I believe the makefiles will become simplier). Thank you, regards, Dima. _______________________________________________
