Improve prep_buildtree

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Improve prep_buildtree
Дата
Msg-id 8b96b07f-1f48-46e9-b26e-01b2c9e4ac8d@eisentraut.org
обсуждение исходный текст
Ответы Re: Improve prep_buildtree
Список pgsql-hackers
Since I started using meson regularly, I have put the build directory 
under the source directory, which appears to be the recommended 
convention.  See for example

https://mesonbuild.com/Quick-guide.html#compiling-a-meson-project

Then, if I also want to create a build directory using configure/make in 
parallel to that (for example, to test the makefiles, if adding new 
source files), then prep_buildtree is a bit stupid about that.  It 
processes all directories under the top-level source directory, 
including existing other build trees, and so it makes a copy of existing 
build trees under the new build tree.  This isn't actually harmful, but 
it seems pretty stupid, and it also makes prep_buildtree slower and 
slower the more build trees you have.

I have never been much of a vpath user before meson, so I don't have 
much experience with it, but I suspect that it was previously the 
convention to have the build tree outside of the source tree, in which 
case this wouldn't have been a problem.

To fix this, I first tried to devise a way to detect whether a given 
directory is a build directory.  But that seemed pretty complicated. 
Instead, I chose the simpler solution that we just enumerate the source 
subdirectories that we know about (config, contrib, doc, src).  That way 
we can also remove the special handling to exclude the .git directory 
and make the find command a bit simpler.

See the attached patch.

Maybe people can try this with their local workflows to make sure it 
still works for them, but I don't expect any particular problems, other 
than perhaps some shell or find command portability issues.  Note, this 
only runs if you do a vpath configure/make build, not an in-tree 
configure/make build, and of course not if you use meson.

Вложения

В списке pgsql-hackers по дате отправления: