[petsc-dev] What is this for?
Matthew Knepley
knepley at gmail.com
Wed Nov 16 07:19:48 CST 2011
On Wed, Nov 16, 2011 at 6:09 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> On Wed, Nov 16, 2011 at 00:47, Sean Farley <sean at mcs.anl.gov> wrote:
>
>> So, this is basically what I think Barry meant ... except the whole /*R
>> <flags> R*/ part.
>
>
> I would want something equivalently verbose because it's HUMAN
> documentation for how the variables are spelled. Even if the build system
> is clairvoyant such that it knows what package each header comes from and
> which variables it needs to link with, a human won't know that and likely
> won't know where to find out. Spelling out those variables, which they can
> query through the makefile include, a CMake include, or Python (preferably
> with the same spelling in each case) makes it understandable.
>
> I don't care about the specifics of the syntax, but I think the variables
> should be spelled out.
>
There is a big difference between
1) Using only the necessary include directories for a given compile,
which might work
and
2) Removing includes we "don't need", which I do not think will work
Starting with 1). This will break things like "make getincludedirs", unless
you want to maintain one
thing with the kitchen sink for users, and one tailored thing for PETSc. I
think this will generate weird
errors where the full line breaks something, but we never see it because we
use the custom build.
I could still support this if we tested the antique version along with the
custom one.
However with 2), how would we distinguish includes we only want if the
package is found from those
that just do not work because of a configuration/build bug? If its
annonation, as Jed suggests, how is
that a step up from #ifdef?
Matt
--
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/20111116/4480fdd1/attachment.html>
More information about the petsc-dev
mailing list