On Nov 15, 2011, at 6:52 PM, Jed Brown wrote: > On Tue, Nov 15, 2011 at 18:48, Matthew Knepley <knepley at gmail.com> wrote: > Yes, but you are advocating a really shitty infrastructure for doing this. > How do you expose these when the user turns out to want > them (like ParMetis for instance)? How do you follow the chain back to find a > bug if you have build logic scattered all over?
It is not scattered all over. The information about a particular source file should be with that file (currently that is done using Unix conventions of a makefile in the directory of the source file). The information should not be in some centralized location away from the source code. Ideally we would not need to list the information separate from the source file. What should happen is the BuildSystem parses each source file, determines what includes are used and then passes to the compiler exactly the correct -I and no extra. Or as alternative the BuildSystem behaves like CPP and actually puts the exact full path for each include into the source code just before passing it to the compiler. This takes the whole bothersome problem of the compiler searching through the -I paths to find the first include file with the same name and including it. In other words BuildSystem takes on more parts of the compile process away from the untrustworthy UNIX tools for compiling and linking. Related is the absurd fact that we have in source code things like #if defined(PETSC_HAVE_MEMORY_H) #include <memory.h> #endif and then in BuildSystem we need to list a test for memory.h; instead BuildSystem should scarf all the #if defined(PETSC_HAVE_MEMORY_H) from the source code and do the tests removing the need for us to manually list the test for memory.h in BuildSystem. This need to manually list facts elsewhere that are actually imbedded in the code is simply due to crappy tools, not because it is a good idea. Satish was the one who advocated many years ago that the actual configure tests be scarfed out of the real source code and it is still a good idea (though maybe hard to implement). One could argue that ParMetis.py should be in the PETSc source code tree in the directory that manages the PETSc interface to ParMetis and not in the packages directory with all the rest. Same with other package files. We can't explore all these possibilities if whenever someone changes something someone else gets upset that someone is using a shitty infrastructure. Barry > > The makefile is already used to indicate which files require optional > packages. > > If the user wants those headers, they can add $PETSC_PARMETIS_INCLUDES to > their compile line and $PETSC_PARMETIS_LIBS to their link line. (Yes, I think > that EVERY variable brought in by conf/variables should be namespaced.) > > We shouldn't break the standard practices for shared libraries just because > you might want to get access to all these optional things without stating > that you want access.
