[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