[petsc-dev] CMake proof of concept
Barry Smith
bsmith at mcs.anl.gov
Mon May 31 19:13:07 CDT 2010
You have an awful lot of confidence in cmake. I have no problem at all setting up a system where PETSc can use cmake, that's great. But I don't want PETSc to ever be in a position
of not being able to do something because kitware/whatever decided that they no longer or would not supported xyz or we have to wait six months for them to "port" to a "new system".
From the point of view of using /usr/bin I don't care that there are thousands of crazy ass things in it. If I were maintaining it I would insist on proper organization. So I am noting thinking of my proposed organization as for the user but instead for the maintainers.
Barry
On May 31, 2010, at 11:46 AM, Jed Brown wrote:
> On Mon, 31 May 2010 11:10:36 -0500, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>
>> Likely we need a subdirectory somewhere to put all the make makers. I would like a subdirectory of bin/maint; likely Matt wants a subdirectory of config
>
> Is this really important? It doesn't seem that messy at this point and
> I don't see the advantage of deep hierarchies, /usr/bin has several
> thousand executables, but it doesn't bother me. I don't have a problem
> with the current setup except that I don't think builder.py should be in
> config.
>
> Also note that iphonebuilder.py might not be strictly necessary:
>
> http://sites.google.com/site/michaelsafyan/coding/resources/how-to-guides/cross-compile-for-the-iphone/how-to-cross-compile-for-the-iphone-using-cmake
>
> I don't know how this will all shake out, but I don't imagine there will
> ever be a lot of these scripts purely for maintenance and support
> reasons. For instance, I could imagine only having a single builder.py
> to just build everything without any external dependencies and CMake for
> IDE integration.
>
> Jed
More information about the petsc-dev
mailing list