On Tue, Oct 16, 2018 at 05:38:15PM +0100, Eric Engestrom wrote: > On Tuesday, 2018-10-16 08:24:02 -0700, Lucas De Marchi wrote: > > On 10/16/18 4:26 AM, Eric Engestrom wrote: > > > On Monday, 2018-10-15 16:48:07 -0700, Lucas De Marchi wrote: > > > > This is the directory used by meson/autotools (at least in the > > > > .gitlab-ci configuration) so ignore the whole dir. > > > > > > This is extremely specific to this one case; what does this change for > > > the gitlab ci? > > > > In order to test locally my changes I always copy and paste the line from > > the CI configuration. And there we are using _build. > > I understand better now, thanks :) > > > Maybe we > > should be using build there and add it to gitignore? We ignore .o, .lo, > > .libs, .deps and build-aux dir. IMO we should ignore the whole build dir now > > that we build out of tree - and _build (or build) dir is the most common to > > use. > > Those were autotools-generated files with partially-predictable names > that were scattered across the source directory; this is considered bad > practice nowadays and modern build systems don't do that anymore, > instead letting the user choose a directory and putting everything in > there. We could add all of these scattered generated files to the > .gitignore, because we knew what the filenames looked like. yeah, my point is entirely like we should support the new build system just like or better than we support the old one. > > With the new method, each user puts their build in their chosen folder, > and while most of us usually chose something with "build" in the name, > there is no structure to this anymore. It's best to simply add your > preferred build-dir-naming-scheme to your clone's ignore list > (.git/info/exclude), which I think is what most of us do (mine has > a /build-*/ line for instance). You can also look at core.excludesfile > if you want to add a global .gitignore for your machine. I think that for specific cases that are different from what the majority use (or at least what we have documented) could go indeed in that file. No reason to make it always go there IMO. > > That said, adding one more line to this file doesn't hurt, so you can do > that if you want, I'm not nack'ing it, but we just can't open the door > to everyone adding their own personal naming scheme to the upstream > .gitignore :) Agree. So what could we add to the .gitignore? _build (what we have in CI) build (what a lot of people use) builddir (what we have in the README) or /_build* /build* to cover all the common uses (and guarantee it's ignored only in the git root dir) Lucas De Marchi > > > > > And it looks like I forgot one patch adding patches/ to the gitignore as > > well (it was what made me look into the gitignore in the first place) :-/. > > Same reason as why it was applied to igt for example: it's common to have a > > patches/ directory to maintain wip patches. > > > > Lucas De Marchi > > > > > > > > > > > > > Signed-off-by: Lucas De Marchi <lucas.demarchi@xxxxxxxxx> > > > > --- > > > > .gitignore | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/.gitignore b/.gitignore > > > > index 49cced50..54365c7c 100644 > > > > --- a/.gitignore > > > > +++ b/.gitignore > > > > @@ -24,6 +24,7 @@ > > > > Makefile > > > > Makefile.in > > > > TAGS > > > > +_build > > > > aclocal.m4 > > > > autom4te.cache > > > > bsd-core/*/@ > > > > -- > > > > 2.19.1.1.g8c3cf03f71 > > > > > > > > _______________________________________________ > > > > dri-devel mailing list > > > > dri-devel@xxxxxxxxxxxxxxxxxxxxx > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > _______________________________________________ > > dri-devel mailing list > > dri-devel@xxxxxxxxxxxxxxxxxxxxx > > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
