Re: Re-organizing source tree regarding drivers?
Andrew Bell via gdal-dev <[email protected]> Mon, 11 May 2026 11:47:22 -0400
| Newsgroups | gmane.comp.gis.gdal.devel |
|---|---|
| Message-ID | <CACJ51z3JFxNtCnQEqVSsWCD11xrmcHRDvDiFUD4Ju9K4MESLjg@mail.gmail.com> |
--===============1143392083750669932== Content-Type: multipart/alternative; boundary="00000000000048de3106518caa30" --00000000000048de3106518caa30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, May 11, 2026 at 11:06=E2=80=AFAM Daniel Baston via gdal-dev < [email protected]> wrote: > While the current organization is definitely not what we'd start with, I'= m > not sure the benefits or reorganization are worth making it harder to > follow the commit history. > This. In particular it's a hassle to trace changes when directories vanish. I think people get used to any arrangement. If this is going to happen, perhaps there are other changes that could be done at the same time. For example, I find it difficult when the header file names don't match the corresponding source files or the classes contained therein. Since I don't work on GDAL every day, I end up spending a bunch of time searching around for things that could be obvious through naming. I also don't love having source files in a separate directory from the headers. (I get that these are perhaps personal preferences not shared by others.) That said, leaving things alone wouldn't be a bad decision, IMO. --=20 Andrew Bell [email protected] --00000000000048de3106518caa30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><div dir= =3D"ltr" class=3D"gmail_attr">On Mon, May 11, 2026 at 11:06=E2=80=AFAM Dani= el Baston via gdal-dev <<a href=3D"mailto:[email protected]">gdal= [email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quo= te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"= ><div dir=3D"ltr">While the current organization is definitely not what we&= #39;d start with, I'm not sure the benefits or reorganization are worth= making it harder to follow the commit history.</div></blockquote><div><br>= </div><div>This.</div><div><br></div><div>In particular it's a hassle t= o trace changes when directories vanish. I think people get used to any arr= angement.<br><br>If this is going to happen, perhaps there are other change= s that could be done at the same time. For example, I find it difficult whe= n the header file names don't match the corresponding source files or t= he classes contained therein. Since I don't work on GDAL every day, I e= nd up spending a bunch of time searching around for things that could be ob= vious through naming. I also don't love having source files in a separa= te directory from the headers. (I get that these are perhaps personal prefe= rences not shared by others.)<br><br>That said, leaving things alone wouldn= 't be a bad decision, IMO.<br><br></div></div><span class=3D"gmail_sign= ature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature" data= -smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Andrew Bell</div><a hr= ef=3D"mailto:[email protected]" target=3D"_blank">andrew.bell.ia@gma= il.com</a></div></div></div> --00000000000048de3106518caa30-- --===============1143392083750669932== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev --===============1143392083750669932==--