Install headers in PREFIX/gdal subdirectory

[mloskot]

Folks, GDAL does not support proper uninstall target and make install spreads all GDAL/OGR headers in PREFIX/include what makes it difficult to clean out easily and without risk other headers will get accidentally removed (note, GDAL lacks of consistent naming of headers!) if one needs to do it.

It would be nice if make install puts all its headers into PREFIX/gdal subdirectory as does it GEOS and most complex libraries.

I mark it as a defect, because installation causes sort of a pollution in file system.

[rouault]

Requested by Ari too in #3469

[ajolma]

Yes, I did request it, and I requested gdal.pc too (#3470) - it could be looked at the same time.

There are in fact a number of things related to the repository - autogen - config - build process that I'd like to address (or be addressed), including cpl_config.h (shouldn't be installed IMO, and autoheader could be used contrary what it says in autogen.sh), I still have problems with xerces config and one other thing in MinGW, swq.h issue (#3468), not storing generated files in repository (wasn't that discussed positively on the list? - do some build environments really require those?). I'm contemplating the idea of making a branch for these things as they are probably not solved very fast.

And, BTW, these are all assigned to warmerdam by default - at least I'm all too eager to accept that and assume things get done. IMO, the reassignments could be done using some head developer authority - similarly as in an editorial board I'm on: I just get emails of tasks assigned to me.

Still one more thing :) I now realize that this may be the developer forum I was looking for. I just wish there was a way of subscribing to some tickets (maybe based on components), I did not find one.

[mloskot]

Ari,

FYI, I reported this ticket as GDAL user, but I'm not going to take any action on implementing it. I have similar concern as yours that they are probably not solved very fast and actually I was submitting this ticket having in mind that it likely will be closed as wontfix, but still I wanted to make it archived, so others can share comments.

Regarding ticket subscriptions, you have two options I think:

• add yourself to CC of particular ticket
• monitor ticket changes with RSS, for example this URL generates RSS channel with 50 recent entries of Ticket changes, Ticket details changes (comments, etc.) from last 10 days

[warmerdam]

For the record, I imagine at some point we will move the GDAL include files into a subdirectory. However, I also believe this will lead to several years of disruption as people try to build packages that depend on GDAL and can't find the include files. This will be very tiresome. I'm not eager to trigger that.

So i'm inclined myself to put off such a change as long as practical and/or till such time as a significant change occurs (perhaps the mythical GDAL 2.0 grand unification).

Ari, if you want to push this much sooner, feel free to bring forward a proposal on the mailing list. I may be unsupportive, but I'll try not to be completely obstructionist. :-)

[ajolma]

Just a short note. I don't think it would necessarily mean disruption, as - really - people should use gdal-config or gdal.pc, and they would report the correct include dir from day one. I've seen this kind of change happen in many packages without any problems to the user (me in those cases). Anyway, I guess this kind of changes is exactly what branches are for.

[warmerdam]

Ari,

Well, I for one have had lots of problems with this sort of change in other packages used by GDAL. GDAL's configure is often unsophisticated about using subpackage config scripts. I'm sure this is also true of many packages using GDAL.

I may be pessimistic, but I've seen a lot of support misery from surprisingly small changes.

I also don't see this as an appropriate change to make in a branch. The problems won't really become evident till an altered GDAL goes into wide distribution and the problems are generally not something we could solve on our side. It will just take time and misery for dependent packages to correct their build mechanisms, and for individual builds to get used to the new configuration.

If we buy that the benefits are worth the misery, then we pick a good time to roll it out ... presumably a major change with other potential disruptions.