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 &lt;<a href=3D"mailto:[email protected]">gdal=
[email protected]</a>&gt; 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&#39;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&#39;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&#39;t match the corresponding source files or t=
he classes contained therein. Since I don&#39;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&#39;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=
&#39;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==--