[petsc-dev] What is this for?

[Matthew Knepley]

On Wed, Nov 16, 2011 at 7:37 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Wed, Nov 16, 2011 at 07:19, Matthew Knepley <knepley at gmail.com> wrote:
>
>> 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.
>>
>
> Since our public headers don't need to include those implementation
> headers, the user does not have access to them unless they personally
> include them. In that case, they should pull the variable out of the
> makefile/cmake/python configuration. We just want to make it completely
> consistent how the necessary variable is named. (Note that this is using
> PETSc as a package manager, not just a library.)
>

1) Nope, we have some package structs in our public interface.

2) Of course they can dig in and pull something out, but the reason we have
"make getincludedirs" is that this is beyond most users

3) We have been a package manager since Barry convinced us to download and
install packages


> If shared libraries are being used, we _should_ be linking libpetsc.so
> such that -lpetsc is enough. Overlinking is bad because it makes the ABI
> more fragile.
>

Nice if we can make it work.


>
>> 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?
>>
>
> So there are two cases
>
> 2a. Include a system header if it exists. It is expected to provide a
> typedef or function that is needed in the public interface (either directly
> by the user or in an inline function). Configure would have checked what is
> available and we have fallback logic if it is not provided. I don't think
> #ifdefs are wrong here.
>
> 2b. Compile an optional implementation which requires some headers. If the
> package is not available, this implementation file is not even compiled.
> This is where that annotation could be useful, so that the build
> environment can stay in the source file instead of being written into the
> makefile or some other independent file. This also reduces the granularity
> with which we can specify compiler flags (it's currently directory-level).
>

How do you distinguish these cases by looking at the source?

   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/2ff94696/attachment.html>