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
