[petsc-dev] reminder never use #include "mylocalinclude.h" in PETSc source

[Matthew Knepley]

On Tue, May 4, 2010 at 1:08 PM, Kai Germaschewski <kai.germaschewski at unh.edu
> wrote:

> I did a lot of work on the linux kernel build system (quite a while ago),
> and somehow the gittup comparison doesn't appear right.
>
> I just counted *.[hc] in linux 2.6.18 (way old, but anyway), that's about
> 21,000 files, and running make on an unchanged, previously built, tree takes
> at most a few seconds. That's a project which is way larger than petsc, and
> make does a "good enough" job there. I'll also dispute that recursive make
> is necessarily wrong, it's quite possible to do things recursively but
> correct, even though it's not optimal for performance (but that is not
> really an issue in a petsc-sized project). Linux kernel relies on gnu make
> features, so it's not really portable, but that's mostly related to the very
> high configurability needs.
>
> In my opinion, you have to take into account a number of aspects when doing
> software. Undoubtedly, make has its flaws, and python is a much nicer
> language, and probably could do the job better. But the flipside is that
> everyone knows make (well, I wish, but anyway), but no outsider is prepared
> to deal with the intricacies of a python based build which is custom made
> for petsc. I think this is important, I don't want to learn a new build
> system, configure, whatever for every project out there, I'd prefer existing
> systems to be used if they're good enough. (OTOH, I wouldn't consider
> petsc's current build good enough, I hate the fact that intermediate files
> are being removed and rebuilding takes forever even if only one file was
> changed)
>
> I just wanted to put this out there. It's not only about your own perfect
> tool, it's also about others who you want to be able to work with the code
> without spending a month learning the tools.
>
> I actually find autoconf/automake fairly usable. They're not pretty, but
> they're used in so many projects, I got used to them, so I actually prefer
> them over the custom configure.py in petsc, even though that's technically a
> lot prettier. Unfortunately, I don't think autotools are usable on windows,
> so cmake or something maybe an alternative to look into. Using one of the
> popular systems certainly would have upsides, IMO.
>

Well, I will take that criticism from people who actually do something to
the configure. I try to remind
myself that for systems where I actually change something, getting inside
the tool matters, otherwise
let them do it their way. We had an entire Autotools build in 2002. It was a
giant, unmaintainable piece
of shit. That is why we switched.

   Matt


> --Kai
>
>
>
> On Tue, May 4, 2010 at 12:51 PM, Jed Brown <jed at 59a2.org> wrote:
>
>> On Tue, 4 May 2010 11:37:14 -0500, Matthew Knepley <knepley at gmail.com>
>> wrote:
>> > I see. Yes, it currently uses the makefile organization. This is the
>> > kind of metadata that Barry would like in a DB rather than in
>> > makefiles.
>>
>> It would be easy to convert between being spread out in the makefiles
>> and being held in some central location.  For instance, something like
>> builder.py, run at the end of configuration time, could instead of
>> building the project, write a single tupfile [1] for all of PETSc, and
>> then we could rejoice with fast correct builds, even after
>> reconfiguring.
>>
>> I think the metadata itself belongs with the implementations (more or
>> less where it is currently) unless we are actually working with an
>> image-based system (which does not look likely in the near future).
>>
>> Jed
>>
>> [1] For those who not in the know: http://gittup.org/tup/make_vs_tup.html
>>
>
>
>
> --
> Kai Germaschewski
> Assistant Professor, Dept of Physics / Space Science Center
> University of New Hampshire, Durham, NH 03824
> office: Morse Hall 245E
> phone:  +1-603-862-2912
> fax: +1-603-862-2771
>
>


-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100504/0373cd88/attachment.html>