Open borupdaniel opened 5 years ago
To me the best behaviors would be (will update this as any discussion below recommends):
.gpirc
file, with an option to ignore it.~/gpi
site-packages
. We discussed a few ways to do this but haven't implemented any yet. I favor looking for packages called gpi_
since this is pretty lightweight and already works for gpi_core
site-packages
libs to the include path. Allow this to be overridden with a flag (same one as below, or should we add another?)./usr/include
and /usr/lib
, which can be overriden with an ignore flag.It might help to be a bit smarter than "two directories up" so that there's more flexibility on where to call gpi_make
. This could be pretty easy: something like "go up directory levels until you run into a gpi
folder, in which case add everything, or a site-packages
folder, in which case add anything starting with gpi_
".
In addition, the site-package
linking happens by default because that folder is now included in the GPI_LIBRARY_PATH
variable. The --ignore-gpirc
flag is a bit misleading - it actually ignores that path variable even if it's not set in .gpirc
at all.
I think the "two directories up" code is only really useful for compiling a single PyMOD file anyway, so maybe we can disable it when --all
is specified? I think that would fix part of this at least for the automated builds.
That seems like a good approach to me.
During a build, if the
--ignore-system-libs
flag isn't included,gpi_make
is still looking two directories upstream and finding lots of python packages insite-packages
. These are then included asinclude_dirs
for the build. I don't know that this is a problem (the build still works fine), but the messages displayed are a little confusing.The library search setup feels a bit hacky in general, so I think this could be part of a clean-up there. Can we come up with a good list of behaviors we want out of
gpi_make
?