rouault
commented
2 years ago the man pages are already generated in the tar ball. The "man" target only works in a git checkout, since the tar ball doesn't include the doc/ subdirectory.
Closed kloczek closed 1 year ago
rouault
commented
2 years ago the man pages are already generated in the tar ball. The "man" target only works in a git checkout, since the tar ball doesn't include the doc/ subdirectory.
kloczek
commented
2 years ago Looks like the similar is with docs target
+ /usr/bin/make -O -j48 V=1 VERBOSE=1 docs -j1
(cd doc; make html)
/bin/sh: line 1: cd: doc: No such file or directory
make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/gdal-3.5.0'
make[1]: *** No rule to make target 'html'. Stop.
make[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/gdal-3.5.0'did you actually build the HTML docs ? Debian had stopped building them because that required Sphinx, etc. That was also removed from the tarball because the CMake target for docs were not working (cf https://github.com/OSGeo/gdal/issues/5483). But perhaps we might revisit that for 3.6.0 if there's interest to build the HTML docs from tarballs.
kloczek
commented
2 years ago As long as docs directory is no no longer part of the dist tar ball I've disabled add that documentation to final packages.
kloczek
commented
2 years ago OK so how to build documentation now? 🤔
rouault
commented
2 years ago I've uploaded in https://download.osgeo.org/gdal/3.5.0/gdal-3.5.0-doc-src.tar.gz the content of the doc/ subdirectory. So if you untar alongside the main archive, you should be able to build docs.
kloczek
commented
2 years ago If documentation is handled now by sphinx to be honest I would be more interested generate man pages. So question still remains .. how to build now devel documentation? 😄
rouault
commented
2 years ago If documentation is handled now by sphinx
"now": it has been like this for years
I would be more interested generate man pages.
as I said, the tarball include them already generated. "make install" will install them
how to build now devel documentation?
What I mentioned in above comment. untar gdal-3.5.0-doc-src.tar.gz, alongside main gdal-3.5.0.tar.gz, so that the doc/ subdirectory is added, and run "make docs" (assuming you have the prerequisites of doc/requirements.txt)
kloczek
commented
2 years ago Hmm .. but why all that is not in single source tar ball? 🤔 Probability that someone will be building gdal without documentation IMO is close to 0.
rouault
commented
2 years ago why all that is not in single source tar ball?
The removal of the doc/ subdirectory in the tarball was probably a confusion of mine (I had the feeling that we didn't package it before, when we moved the content of gdal/* to top directory of the git repository, but I was wrong as it was present in the 3.4.x tarball). But actually, I'm no sure it is a wrong move, as it also helps making the main tarball smaller
Probability that someone will be building gdal without documentation IMO is close to 0.
I would have said the contrary from the overall feedback we got until here. Packagers from which we get regular feedback seem to have stopped building the docs since we switched to Sphinx, and most people just rely on the pregenerated HTML doc in the http://download.osgeo.org/gdal/3.5.0/gdal350doc.zip archive, or on https://gdal.org. And for man pages, "make install" does the job with the pregenerated man pages.
CC @sebastic @gdt
kloczek
commented
2 years ago Hmm looking on content of the gdal-3.5.0-doc-src.tar.gz found quite complicated cmak files. Looks like all of that can be dropped if doc/source/conf.py is well written whole documentation in desired format shuld be possible to build using single command like
sphinx-build -n -T -b man doc/source build/sphinx/manI have more and more impression that by splitting source tree to different tar balls and adding own cmake files you are overcomplicating everything 🤔 I would rather give chance to build gdal from autogenerated from git tag tar ball https://github.com/OSGeo/gdal/archive/refs/tags/v3.5.0.tar.gz If it will be working additionally will have 100% guarantee that I would be able use any git commit added after release so in case any JFDI fixes it will be easier to integrate everything with post release fixes.
kloczek
commented
2 years ago Instead wasting time on complicating release process, splitting source code, uploading somewhere dist tar balls etc. I would recommend focus on maxim reuse autogenerated tar balls from tags. Tagging can be additionally signed. You can read about how to do that on https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-tags
rouault
commented
2 years ago found quite complicated cmake files.
The CMakeLists.txt for doc/ are not ready (was one of the reason to remove doc/ from the tarball if I remember correctly). And even once fixed, it would likely be intended to be used as part of the main build, not standalone.
Instead wasting time on complicating release process
Please be gentle with us. We spent huge efforts adding the CMake build system, and the transition period with autoconf + CMake is complicated to handle.
instead of splitting source code
We have always split the tarballs for (source + doc) from the one from autotests. Regarding doc, I'm not sure what to do, as there's no consensus on how to handle that.
sebastic
commented
2 years ago Probability that someone will be building gdal without documentation IMO is close to 0.
I would have said the contrary from the overall feedback we got until here. Packagers from which we get regular feedback seem to have stopped building the docs since we switched to Sphinx, and most people just rely on the pregenerated HTML doc in the http://download.osgeo.org/gdal/3.5.0/gdal350doc.zip archive, or on https://gdal.org. And for man pages, "make install" does the job with the pregenerated man pages.
The Debian package removed the doc directory since 3.1.0-rc1 because license and copyright review is a PITA with the inclusion of the RTD fork. The libgdal-doc package wasn't very popular, so not a big loss for users, the online documentation suits most users just fine.
kloczek
commented
2 years ago Please be gentle with us. We spent huge efforts adding the CMake build system, and the transition period with autoconf + CMake is complicated to handle.
If you guys forcing me to update build procedure almost every release because you have some brilliant idea .. sorry please stick to KISS principle and be on the distance from BecauseWeCan™️ Sorry for maybe bitter words but sticking to "Don't move, improve" and KISS may have more real value.
The Debian package removed the doc directory since 3.1.0-rc1 because license and copyright review is a PITA with the inclusion of the RTD fork.
So .. why not start distribute everything under one common licence or set of licences to make packagers life easier? 🤔
If you really want to move away from GNU auto tools please move to meson. This only build framework which provides interface which can be easily plugged into complicated packages set population system because it provides something like that
[tkloczko@devel-g2v rhythmbox-3.4.5]$ meson introspect --dependencies x86_64-redhat-linux-gnu | jq 'del( .[] .compile_args, .[] .link_args)'
[
{
"name": "cairo",
"version": "1.17.6"
},
{
"name": "gdk-pixbuf-2.0",
"version": "2.42.8"
},
{
"name": "gio-2.0",
"version": "2.72.0"
},
{
"name": "gio-unix-2.0",
"version": "2.72.0"
},
{
"name": "glib-2.0",
"version": "2.72.0"
},
{
"name": "gmodule-export-2.0",
"version": "2.72.0"
},
{
"name": "gobject-2.0",
"version": "2.72.0"
},
{
"name": "gobject-introspection-1.0",
"version": "1.72.0"
},
{
"name": "gstreamer-1.0",
"version": "1.20.1"
},
{
"name": "gstreamer-audio-1.0",
"version": "1.20.0"
},
{
"name": "gstreamer-base-1.0",
"version": "1.20.1"
},
{
"name": "gstreamer-controller-1.0",
"version": "1.20.1"
},
{
"name": "gstreamer-plugins-base-1.0",
"version": "1.20.0"
},
{
"name": "gstreamer-pbutils-1.0",
"version": "1.20.0"
},
{
"name": "gstreamer-tag-1.0",
"version": "1.20.0"
},
{
"name": "gtk+-3.0",
"version": "3.24.31"
},
{
"name": "json-glib-1.0",
"version": "1.6.6"
},
{
"name": "libpeas-1.0",
"version": "1.32.0"
},
{
"name": "libpeas-gtk-1.0",
"version": "1.32.0"
},
{
"name": "libsoup-2.4",
"version": "2.74.2"
},
{
"name": "libxml-2.0",
"version": "2.9.14"
},
{
"name": "pango",
"version": "1.50.7"
},
{
"name": "tdb",
"version": "1.4.6"
},
{
"name": "totem-plparser",
"version": "3.26.6"
},
{
"name": "gudev-1.0",
"version": "237"
},
{
"name": "libgpod-1.0",
"version": "0.8.3"
},
{
"name": "libmtp",
"version": "1.1.19"
},
{
"name": "libnotify",
"version": "0.7.11"
},
{
"name": "libsecret-1",
"version": "0.20.5"
},
{
"name": "lirc",
"version": "0.10.1"
},
{
"name": "libbrasero-media3",
"version": "3.12.3"
},
{
"name": "x11",
"version": "1.7.5"
},
{
"name": "pygobject-3.0",
"version": "3.42.1"
},
{
"name": "libdmapsharing-4.0",
"version": "3.9.10"
},
{
"name": "grilo-0.3",
"version": "0.3.14"
},
{
"name": "check",
"version": "0.15.2"
}
]That is only one extracted aspect of metadata which meson metric as set of JSON METRICS easy to process by any automation above single package.
rouault
commented
2 years ago So .. why not start distribute everything under one common licence or set of licences to make packagers life easier?
I'm not sure what the licensing issue is really. The license of read-the-docs is MIT (https://github.com/readthedocs/readthedocs.org/blob/main/LICENSE), and the fork of it we inherited to is also MIT: https://github.com/OSGeo/gdal/blob/master/doc/source/gdal_rtd/LICENSE
If you really want to move away from GNU auto tools please move to meson.
The move to CMake was discussed and approved many months ago: https://gdal.org/development/rfc/rfc84_cmake.html . We're not going to change from build system in the next 10 years hopefully.
kloczek
commented
2 years ago BTW just checked what I have in my set of patches against gdal:
gcc 11+ fix
diff -rupN --no-dereference gdal-3.4.1-fedora/ogr/ogrsf_frmts/cad/libopencad/cadobjects.cpp gdal-3.4.1-fedora-new/ogr/ogrsf_frmts/cad/libopencad/cadobjects.cpp
--- gdal-3.4.1-fedora/ogr/ogrsf_frmts/cad/libopencad/cadobjects.cpp 2021-12-27 21:26:29.000000000 +0100
+++ gdal-3.4.1-fedora-new/ogr/ogrsf_frmts/cad/libopencad/cadobjects.cpp 2022-01-04 13:58:03.552554655 +0100
@@ -34,6 +34,7 @@
#include <limits>
#include <math.h>
#include <algorithm>
+#include <limits>
//------------------------------------------------------------------------------
// CADVector
diff -rupN --no-dereference gdal-3.4.1-fedora/ogr/ogrsf_frmts/cad/libopencad/dwg/r2000.cpp gdal-3.4.1-fedora-new/ogr/ogrsf_frmts/cad/libopencad/dwg/r2000.cpp
--- gdal-3.4.1-fedora/ogr/ogrsf_frmts/cad/libopencad/dwg/r2000.cpp 2021-12-27 21:26:28.000000000 +0100
+++ gdal-3.4.1-fedora-new/ogr/ogrsf_frmts/cad/libopencad/dwg/r2000.cpp 2022-01-04 13:58:03.552554655 +0100
@@ -39,6 +39,7 @@
#include <limits>
#include <memory>
#include <string>
+#include <limits>
#if ((defined(__sun__) || defined(__FreeBSD__)) && __GNUC__ == 4 && __GNUC_MINOR__ == 8) || defined(__ANDROID__)
// gcc 4.8 on Solaris 11.3 or FreeBSD 11 doesn't have std::string
diff -rupN --no-dereference gdal-3.4.1-fedora/third_party/LercLib/Lerc2.h gdal-3.4.1-fedora-new/third_party/LercLib/Lerc2.h
--- gdal-3.4.1-fedora/third_party/LercLib/Lerc2.h 2021-12-27 21:25:37.000000000 +0100
+++ gdal-3.4.1-fedora-new/third_party/LercLib/Lerc2.h 2022-01-04 13:58:03.553554660 +0100
@@ -30,6 +30,7 @@ Contributors: Thomas Maurer
#include <limits>
#include <string>
#include <typeinfo>
+#include <limits>
#include "Defines.h"
#include "BitMask.h"
#include "BitStuffer2.h"PKG_PROG_PKG_CONFIG aclocal macro
--- a//configure.ac~ 2022-05-10 14:03:37.000000000 +0000
+++ b//configure.ac 2022-05-13 20:04:47.135960919 +0000
@@ -220,6 +220,8 @@
AC_PROG_CXX
LT_INIT([win32-dll])+PKG_PROG_PKG_CONFIG([0.21]) + dnl Check that CXX is really a working compiler AC_LANG_PUSH([C++]) AC_COMPILE_IFELSE([AC_LANG_PROGRAM( @@ -1987,7 +1989,6 @@
else
PKG_PROG_PKG_CONFIG([0.21]) PKG_CHECK_MODULES([PQ],[libpq > 9.1], [HAVE_PG=yes], [HAVE_PG=no])
if test "${HAVE_PG}" = "yes" ; then @@ -2617,7 +2618,6 @@
elif test "$with_mongocxxv3" = "yes" -o "$with_mongocxxv3" = "" ; then
PKG_PROG_PKG_CONFIG([0.21]) PKG_CHECK_MODULES([MONGOCXXV3], [libmongocxx >= 3.4.0], [MONGOCXXV3_ENABLED=yes], [MONGOCXXV3_ENABLED=no])
if test "$MONGOCXXV3_ENABLED" = "no" -a "$with_mongocxxv3" = "yes" ; then @@ -2770,7 +2770,6 @@
HDF5_CFLAGS="" HDF5_LIBS=""
PKG_PROG_PKG_CONFIG([0.21]) # check and set $PKG_CONFIG PKG_CHECK_MODULES([HDF5], [hdf5], [HAVE_HDF5=yes], [HAVE_HDF5=no])
if test "$HAVE_HDF5" = "yes"; then @@ -3092,7 +3091,6 @@
else
PKG_PROG_PKG_CONFIG([0.21])
PKG_CHECK_MODULES([OPENJPEG], [libopenjp2 >= 2.1.0],
[OPENJPEG_VERSION=$PKG_CONFIG --modversion libopenjp2],
[OPENJPEG_VERSION=;])
@@ -3900,7 +3898,6 @@
if test "x$with_xml2" = "xyes" -o "x$with_xml2" = "x" ; then
PKG_PROG_PKG_CONFIG([0.21]) PKG_CHECK_MODULES(LIBXML2,[libxml-2.0], [HAVE_LIBXML2=yes], [HAVE_LIBXML2=no])
if test "${HAVE_LIBXML2}" = "yes"; then @@ -4228,7 +4225,6 @@ with_qhull_pkgname=qhull_r fi
PKG_PROG_PKG_CONFIG([0.21]) PKG_CHECK_MODULES([QHULL],[$with_qhull_pkgname], [HAVE_QHULL=yes], [HAVE_QHULL=no])
dnl First try with pkg-config @@ -4527,7 +4523,6 @@
if test "$with_poppler" != "no" -a "$with_poppler" != ""; then
PKG_PROG_PKG_CONFIG([0.21])
PKG_CHECK_MODULES([POPPLER], [poppler >= 0.23.0],
[POPPLER_VERSION=$PKG_CONFIG --modversion poppler], [POPPLER_VERSION=])
if test "$POPPLER_VERSION" != ""; then
@@ -5489,7 +5484,6 @@
else
PKG_PROG_PKG_CONFIG([0.21]) PKG_CHECK_MODULES([EXR], [OpenEXR >= 2.2], [HAVE_EXR=yes], [HAVE_EXR=no])
if test -n "$EXR_CFLAGS"; then @@ -5530,7 +5524,6 @@
else
PKG_PROG_PKG_CONFIG([0.21]) PKG_CHECK_MODULES([HEIF], [libheif >= 1.1], [], [HAVE_HEIF=no])
if test -n "$HEIF_LIBS"; then @@ -5566,7 +5559,6 @@
else
PKG_PROG_PKG_CONFIG([0.21]) PKG_CHECK_MODULES([JXL], [libjxl], [], [HAVE_JXL=no])
if test -n "$JXL_LIBS" ; then
- insyalling apps fix
```patch
diff -rupN --no-dereference gdal-3.4.1-fedora/apps/GNUmakefile gdal-3.4.1-fedora-new/apps/GNUmakefile
--- gdal-3.4.1-fedora/apps/GNUmakefile 2021-12-27 21:25:11.000000000 +0100
+++ gdal-3.4.1-fedora-new/apps/GNUmakefile 2022-01-04 13:58:03.039552414 +0100
@@ -232,6 +232,7 @@ gdal-config-inst: gdal-config.in ../GDAL
install: default
for f in $(BIN_LIST) ; do $(INSTALL) $$f $(DESTDIR)$(INST_BIN) ; done
+ for f in $(BIN_LIST) ; do $(INSTALL) .libs/$$f $(DESTDIR)$(INST_BIN) ; done
$(INSTALL_DATA) gdal_utils.h $(DESTDIR)$(INST_INCLUDE)
$(INSTALL) gdal-config-inst $(DESTDIR)$(INST_BIN)/gdal-config
diff -rupN --no-dereference gdal-3.4.1-fedora/m4/lib-link.m4 gdal-3.4.1-fedora-new/m4/lib-link.m4
--- gdal-3.4.1-fedora/m4/lib-link.m4 2021-12-27 21:26:46.000000000 +0100
+++ gdal-3.4.1-fedora-new/m4/lib-link.m4 2022-01-04 13:58:04.019556695 +0100
@@ -108,8 +108,6 @@ dnl acl_hardcode_direct,
dnl acl_hardcode_minus_L.
AC_DEFUN([AC_LIB_RPATH],
[
--- a/configure.ac~ 2022-05-22 16:33:02.000000000 +0000
+++ b/configure.ac 2022-05-22 16:34:07.298890134 +0000
@@ -48,169 +48,6 @@
dnl type variable $host
AC_CANONICAL_HOSTecho "$C_WFLAGS " | sed "s/-Wdeclaration-after-statement //"-dnl g++-4.8 complain a bit too much with -Weffc++ -if test "$WARN_EFFCPLUSPLUS" != ""; then
-dnl Clang enables -Woverloaded-virtual if -Wall is defined, but not GCC -AX_CHECK_COMPILE_FLAG([-Woverloaded-virtual], [CXX_WFLAGS="$CXX_WFLAGS -Woverloaded-virtual"],,[$ERROR_ON_UNKNOWN_OPTIONS])
-dnl Forbid use of 'or', 'and', ... alias operators -AX_CHECK_COMPILE_FLAG([-fno-operator-names], [CXX_WFLAGS="$CXX_WFLAGS -fno-operator-names"],,[$ERROR_ON_UNKNOWN_OPTIONS])
-HAVE_GCC_WARNING_ZERO_AS_NULL_POINTER_CONSTANT=no -AX_CHECK_COMPILE_FLAG([-Wzero-as-null-pointer-constant], [CXX_WFLAGS="$CXX_WFLAGS -Wzero-as-null-pointer-constant" HAVE_GCC_WARNING_ZERO_AS_NULL_POINTER_CONSTANT=yes],,[$ERROR_ON_UNKNOWN_OPTIONS]) -if test "$HAVE_GCC_WARNING_ZERO_AS_NULL_POINTER_CONSTANT" = "yes"; then -AC_DEFINE_UNQUOTED(HAVE_GCC_WARNING_ZERO_AS_NULL_POINTER_CONSTANT, 1,
-AC_LANG_POP([C++])
-CXX14_SUPPORT=no -AC_ARG_WITH([cpp14],
-AC_MSG_CHECKING([if use C++14 compiler options]) -if test "$with_cpp14" = "yes"; then
-if [test "$CXX14_SUPPORT" = "no"]; then
-dnl Available in GCC 5.1 -AC_LANG_PUSH([C++])
-dnl Enable -Wimplicit-fallthrough only if C++11 is enabled since CPL_FALLTHROUGH is only active then -AC_LANG_PUSH([C++]) -SAVED_CXXFLAGS=$CXXFLAGS -CXXFLAGS="$CXXFLAGS $ERROR_ON_UNKNOWN_OPTIONS -Wimplicit-fallthrough" -AC_MSG_CHECKING([if -Wimplicit-fallthrough can be enabled]) -AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
-AC_SUBST(CXX_WFLAGS,$CXX_WFLAGS) -AC_SUBST(C_WFLAGS,$C_WFLAGS) -AC_SUBST(NO_UNUSED_PARAMETER_FLAG,$NO_UNUSED_PARAMETER_FLAG) -AC_SUBST(NO_SIGN_COMPARE,$NO_SIGN_COMPARE) -AC_SUBST(NO_NON_VIRTUAL_DTOR_FLAG,$NO_NON_VIRTUAL_DTOR_FLAG) -AC_SUBST(NO_LOGICAL_OP_FLAG,$NO_LOGICAL_OP_FLAG) -AC_SUBST(WARN_OLD_STYLE_CAST,$WARN_OLD_STYLE_CAST) -AC_SUBST(WARN_EFFCPLUSPLUS,$WARN_EFFCPLUSPLUS)
dnl Checks for programs.
dnl AC_PROG_CC_C99 is deprecated since autoconf 2.70 --- a/GDALmake.opt.in~ 2022-05-10 14:03:37.000000000 +0000 +++ b/GDALmake.opt.in 2022-05-22 16:30:50.759802419 +0000 @@ -74,40 +74,22 @@ INST_WEB = $(HOME)/www/gdal
CPPFLAGS := @CPPFLAGS@ -iquote $(GDAL_ROOT)/port -iquote $(GDAL_ROOT)/generated_headers @EXTRA_INCLUDES@ -DGDAL_COMPILATION -CFLAGS = @CFLAGS@ @C_WFLAGS@ $(USER_DEFS) -CXXFLAGS = @CXXFLAGS@ @CXX_WFLAGS@ $(USER_DEFS) -CFLAGS_NOFTRAPV = @CFLAGS_NOFTRAPV@ @C_WFLAGS@ $(USER_DEFS) -CXXFLAGS_NOFTRAPV = @CXXFLAGS_NOFTRAPV@ @CXX_WFLAGS@ $(USER_DEFS) -CXXFLAGS_NO_LTO_IF_SSSE3_NONDEFAULT = @CXXFLAGS_NO_LTO_IF_SSSE3_NONDEFAULT@ @CXX_WFLAGS@ $(USER_DEFS) -CXXFLAGS_NO_LTO_IF_AVX_NONDEFAULT = @CXXFLAGS_NO_LTO_IF_AVX_NONDEFAULT@ @CXX_WFLAGS@ $(USER_DEFS) +CFLAGS = @CFLAGS@ $(USER_DEFS) +CXXFLAGS = @CXXFLAGS@ $(USER_DEFS) +CFLAGS_NOFTRAPV = @CFLAGS_NOFTRAPV@ $(USER_DEFS) +CXXFLAGS_NOFTRAPV = @CXXFLAGS_NOFTRAPV@ $(USER_DEFS) +CXXFLAGS_NO_LTO_IF_SSSE3_NONDEFAULT = @CXXFLAGS_NO_LTO_IF_SSSE3_NONDEFAULT@ $(USER_DEFS) +CXXFLAGS_NO_LTO_IF_AVX_NONDEFAULT = @CXXFLAGS_NO_LTO_IF_AVX_NONDEFAULT@ $(USER_DEFS)
NO_UNUSED_PARAMETER_FLAG = @NO_UNUSED_PARAMETER_FLAG@ NO_SIGN_COMPARE = @NO_SIGN_COMPARE@ NO_NON_VIRTUAL_DTOR_FLAG = @NO_NON_VIRTUAL_DTOR_FLAG@ NO_LOGICAL_OP_FLAG = @NO_LOGICAL_OP_FLAG@ -WARN_OLD_STYLE_CAST = @WARN_OLD_STYLE_CAST@ -WARN_EFFCPLUSPLUS = @WARN_EFFCPLUSPLUS@
LDFLAGS = @LDFLAGS@ -# LDFLAGS += -fsanitize=address
RANLIB = @RANLIB@ SO_EXT = @SO_EXT@ --- a/frmts/sigdem/GNUmakefile~ 2020-09-01 09:36:30.000000000 +0100 +++ b/frmts/sigdem/GNUmakefile 2020-10-12 11:11:51.959136327 +0100 @@ -2,8 +2,6 @@
OBJ = sigdemdataset.o
default: $(OBJ:.o=.$(OBJ_EXT))
clean: --- a/frmts/vrt/GNUmakefile~ 2020-09-01 09:36:30.000000000 +0100 +++ b/frmts/vrt/GNUmakefile 2020-10-12 11:14:22.160107696 +0100 @@ -6,7 +6,6 @@ OBJ += pixelfunctions.o vrtmultidim.o
CPPFLAGS := $(CPPFLAGS) -CXXFLAGS := $(WARN_EFFCPLUSPLUS) $(WARN_OLD_STYLE_CAST) $(CXXFLAGS)
ifeq ($(HAVE_GEOS),yes) CPPFLAGS := -DHAVE_GEOS=1 $(CPPFLAGS) --- a/gcore/GNUmakefile~ 2020-09-01 09:36:31.000000000 +0100 +++ b/gcore/GNUmakefile 2020-10-12 11:17:26.754072503 +0100 @@ -43,8 +43,6 @@ OBJ += nasakeywordhandler.o endif
GENERATE_GDAL_VERSION_H := $(shell ./generate_gdal_version_h.sh)
default: mdreader-target $(OBJ:.o=.$(OBJ_EXT)) rasterio_ssse3.$(OBJ_EXT) --- a/ogr/ogrsf_frmts/generic/GNUmakefile~ 2020-09-01 09:36:31.000000000 +0100 +++ b/ogr/ogrsf_frmts/generic/GNUmakefile 2020-10-12 12:11:45.507445755 +0100 @@ -11,8 +11,6 @@
CXXFLAGS := $(CXXFLAGS) $(SHADOW_WFLAGS) -DINST_DATA=\"$(INST_DATA)\"
CXXFLAGS := $(CXXFLAGS) -DGENERIC_ENABLED -DGEOJSON_ENABLED -DKML_ENABLED -DMEM_ENABLED -DMITAB_ENABLED -DVRT_ENABLED $(OGR_FORMATS_ENABLED_CFLAGS)
ifeq ($(HAVE_OGDI),yes) --- a/ogr/ogrsf_frmts/shape/GNUmakefile~ 2020-09-01 09:36:31.000000000 +0100 +++ b/ogr/ogrsf_frmts/shape/GNUmakefile 2020-10-12 12:12:42.155480184 +0100 @@ -12,8 +12,6 @@ CPPFLAGS := $(CPPFLAGS) -DRENAME_INTERNAL_SHAPELIB_SYMBOLS -DSHPAPI_CALL= endif
default: $(O_OBJ:.o=.$(OBJ_EXT))
$(OBJ) $(O_OBJ): ogrshape.h shapefil.h shpopen.c dbfopen.c shptree.c sbnsearch.c --- a/frmts/iso8211/Makefile.in~ 2020-09-01 09:36:30.000000000 +0100 +++ b/frmts/iso8211/Makefile.in 2020-10-12 12:43:37.841548536 +0100 @@ -6,7 +6,6 @@ cpl_vsil.o cpl_vsi_mem.o cpl_vsil_unix_stdio_64.o cpl_dir.o \ cpl_conv.o cpl_path.o
-CXXFLAGS = @CXXFLAGS@ @CXX_WFLAGS@ LIBS = @LIBS@ -lm CXX = @CXX@
--- a/frmts/sdts/Makefile.in~ 2020-09-01 09:36:30.000000000 +0100 +++ b/frmts/sdts/Makefile.in 2020-10-12 12:47:59.672663020 +0100 @@ -11,7 +11,6 @@ \ cpl_error.o cpl_vsisimple.o cpl_string.o cpl_conv.o cpl_path.o
-CXXFLAGS = @CXXFLAGS@ @CXX_WFLAGS@ LIBS = @LIBS@ -lm CXX = @CXX@
--- a/frmts/gta/GNUmakefile~ 2020-09-01 09:36:30.000000000 +0100 +++ b/frmts/gta/GNUmakefile 2020-10-12 13:16:58.244466373 +0100 @@ -3,8 +3,6 @@
OBJ = gtadataset.o
default: $(OBJ:.o=.$(OBJ_EXT))
clean: --- a/port/GNUmakefile~ 2021-04-26 13:29:56.000000000 +0100 +++ b/port/GNUmakefile 2021-05-09 17:06:50.837088440 +0100 @@ -15,8 +15,6 @@
CPPFLAGS := $(CPPFLAGS) $(CURL_INC) $(JSON_INCLUDE) $(XTRA_OPT) -DINST_DATA=\"$(INST_DATA)\" -DSYSCONFDIR=\"$(sysconfdir)\"
OBJ = cpl_conv.o cpl_error.o cpl_string.o cplgetsymbol.o cplstringlist.o \ cpl_strtod.o cpl_path.o cpl_csv.o cpl_findfile.o cpl_minixml.o \ cpl_multiproc.o cpl_list.o cpl_getexecpath.o cplstring.o \ --- a/frmts/raw/GNUmakefile~ 2021-04-26 13:29:56.000000000 +0100 +++ b/frmts/raw/GNUmakefile 2021-05-09 17:08:31.944324605 +0100 @@ -10,8 +10,6 @@ krodataset.o roipacdataset.o iscedataset.o rrasterdataset.o \ byndataset.o
default: $(OBJ:.o=.$(OBJ_EXT))
clean: --- a/ogr/GNUmakefile~ 2022-03-08 10:10:53.000000000 +0000 +++ b/ogr/GNUmakefile 2022-04-17 07:23:01.650091090 +0000 @@ -33,8 +33,6 @@
CPPFLAGS := -iquote ogrsf_frmts -iquote ogrsf_frmts/mem -iquote ogrsf_frmts/geojson $(JSON_INCLUDE) -iquote . $(PROJ_INCLUDE) $(PROJ_FLAGS) $(CPPFLAGS) $(ZLIB_XTRA_OPT)
default: lib
all: lib @@ -96,4 +96,4 @@ rm swq_parser.cpp.bak
swq_parser.$(OBJ_EXT): swq_parser.cpp
$(CXX) $(GDAL_INCLUDE) $(CXXFLAGS) $(CPPFLAGS) -c -o $@ $< --- a/frmts/gtiff/GNUmakefile~ 2022-03-08 10:10:53.000000000 +0000 +++ b/frmts/gtiff/GNUmakefile 2022-04-17 07:26:18.493132186 +0000 @@ -48,9 +48,6 @@
CPPFLAGS := -iquote .. $(GEOTIFF_INCLUDE) $(PROJ_INCLUDE) $(PROJ_FLAGS) $(TIFF_OPTS) $(CPPFLAGS)
default: $(OBJ:.o=.$(OBJ_EXT)) $(SUBLIBS)
clean: --- a/frmts/postgisraster/GNUmakefile~ 2022-03-08 10:10:53.000000000 +0000 +++ b/frmts/postgisraster/GNUmakefile 2022-04-17 07:27:36.677149815 +0000 @@ -8,8 +8,6 @@
CPPFLAGS := -iquote ../mem -iquote ../vrt $(XTRA_OPT) $(PG_INC) $(CPPFLAGS)
default: $(OBJ:.o=.$(OBJ_EXT))
$(O_OBJ): postgisraster.h ../vrt/vrtdataset.h ../mem/memdataset.h --- a/ogr/ogrsf_frmts/mitab/GNUmakefile~ 2022-03-08 10:10:53.000000000 +0000 +++ b/ogr/ogrsf_frmts/mitab/GNUmakefile 2022-04-17 07:28:58.051168155 +0000 @@ -16,8 +16,6 @@ CPPFLAGS := -iquote .. -iquote ../.. $(CPPFLAGS) -DOGR \ -DMITAB_USE_OFTDATETIME
default: $(O_OBJ:.o=.$(OBJ_EXT))
clean: --- a/ogr/ogrsf_frmts/amigocloud/pkg/Makefile.in~ 2022-03-08 10:10:53.000000000 +0000 +++ b/ogr/ogrsf_frmts/amigocloud/pkg/Makefile.in 2022-04-17 07:30:58.006195199 +0000 @@ -6,7 +6,7 @@
CPPFLAGS = -DUSE_CPL $(JSON_INCLUDE) -iquote .. -iquote ../.. -iquote ../pgdump \ @GDAL_INC@ @PQ_INCLUDE@ @CPPFLAGS@ -CXXFLAGS = @CXX_WFLAGS@ @CXX_PIC@ +CXXFLAGS = @CXXFLAGS@ @CXX_PIC@ CFLAGS = @CFLAGS@ LDFLAGS = @LDFLAGS@
--- a/alg/GNUmakefile~ 2022-03-08 10:10:52.000000000 +0000 +++ b/alg/GNUmakefile 2022-04-17 07:52:53.235576278 +0000 @@ -37,17 +37,15 @@
CPPFLAGS := -iquote ../frmts/vrt -iquote ../frmts/mem $(CPPFLAGS) $(OPENCL_FLAGS) $(PROJ_FLAGS) $(PROJ_INCLUDE) -iquote marching_squares
default: $(OBJ:.o=.$(OBJ_EXT)) gdalgridavx.$(OBJ_EXT) gdalgridsse.$(OBJ_EXT)
gdalgridavx.$(OBJ_EXT): gdalgridavx.cpp
$(CXX) $(GDAL_INCLUDE) $(CXXFLAGS_NO_LTO_IF_AVX_NONDEFAULT) $(AVXFLAGS) $(CPPFLAGS) -c -o $@ $<
gdalgridsse.$(OBJ_EXT): gdalgridsse.cpp
$(CXX) $(GDAL_INCLUDE) $(CXXFLAGS) $(SSEFLAGS) $(CPPFLAGS) -c -o $@ $<
clean: $(RM) *.o $(O_OBJ) --- a/frmts/northwood/GNUmakefile~ 2022-03-08 10:10:53.000000000 +0000 +++ b/frmts/northwood/GNUmakefile 2022-04-17 08:03:52.432868243 +0000 @@ -6,8 +6,6 @@
CPPFLAGS := $(CPPFLAGS) $(XTRA_OPT)
default: $(OBJ:.o=.$(OBJ_EXT))
clean: --- a/frmts/stacta/GNUmakefile~ 2022-03-08 10:10:53.000000000 +0000 +++ b/frmts/stacta/GNUmakefile 2022-04-17 08:15:39.516075027 +0000 @@ -2,7 +2,7 @@
OBJ = stactadataset.o
-CXXFLAGS := $(WARN_EFFCPLUSPLUS) $(CXXFLAGS) -iquote ../mem +CXXFLAGS := $(CXXFLAGS) -iquote ../mem
default: $(OBJ:.o=.$(OBJ_EXT))
--- a/ogr/ogrsf_frmts/pg/GNUmakefile~ 2022-03-08 10:10:53.000000000 +0000 +++ b/ogr/ogrsf_frmts/pg/GNUmakefile 2022-04-17 08:18:08.016128585 +0000 @@ -7,8 +7,6 @@
CPPFLAGS := $(PG_INC) -iquote ../pgdump $(CPPFLAGS)
default: $(O_OBJ:.o=.$(OBJ_EXT))
clean: --- a/frmts/stacit/GNUmakefile~ 2022-03-08 10:10:53.000000000 +0000 +++ b/frmts/stacit/GNUmakefile 2022-04-17 08:19:49.631167767 +0000 @@ -2,7 +2,7 @@
OBJ = stacitdataset.o
-CXXFLAGS := $(WARN_EFFCPLUSPLUS) $(CXXFLAGS) -iquote ../vrt +CXXFLAGS := $(CXXFLAGS) -iquote ../vrt
default: $(OBJ:.o=.$(OBJ_EXT))
--- a/frmts/zarr/GNUmakefile~ 2022-05-10 14:03:38.000000000 +0000 +++ b/frmts/zarr/GNUmakefile 2022-05-13 20:06:47.272991402 +0000 @@ -10,8 +10,6 @@
CPPFLAGS := -iquote ../mem -iquote ../netcdf $(CPPFLAGS) $(XTRA_OPT)
$(O_OBJ): zarr.h
default: $(OBJ:.o=.$(OBJ_EXT))
This was e specially hard to prepare as that block using `CC=<static_code_analyser_or_autitin_tool> make` which do not recognise many gcc warning options. If you need to have proper view of some compile time warnings please use only on CI something like "CFLAGS="-Wfoo -Wbar "./configure <options>` instead hardcoding all that crap straight into the code which other people may find as completely useless.
That approach would allow make build procedure much ready for use case which you may have no idea that other people are using on daily baseses.
Please let me know if you want any of those patches as PRs.Yet another small patch which was necessary to apply to have proper LTO optimisation
diff -rupN --no-dereference gdal-3.4.1-fedora/frmts/iso8211/GNUmakefile gdal-3.4.1-fedora-new/frmts/iso8211/GNUmakefile
--- gdal-3.4.1-fedora/frmts/iso8211/GNUmakefile 2021-12-27 21:25:11.000000000 +0100
+++ gdal-3.4.1-fedora-new/frmts/iso8211/GNUmakefile 2022-01-04 13:58:02.496550043 +0100
@@ -23,8 +23,7 @@ dist-clean: clean
rm -rf $(DISTDIR)
$(ISOLIB): $(OBJ:.o=.$(OBJ_EXT))
- $(AR) r $(ISOLIB) $?
- $(RANLIB) $(ISOLIB)
+ $(SHELL) $(top_builddir)/libtool --mode=link $(CC) -static -o $(ISOLIB) $?
8211createfromxml$(EXE): 8211createfromxml.$(OBJ_EXT)
$(LD) $(LDFLAGS) 8211createfromxml.$(OBJ_EXT) $(CONFIG_LIBS) -o 8211createfromxml$(EXE)
jmckenna
commented
2 years ago I would have said the contrary from the overall feedback we got until here. Packagers from which we get regular feedback seem to have stopped building the docs since we switched to Sphinx, and most people just rely on the pregenerated HTML doc in the http://download.osgeo.org/gdal/3.5.0/gdal350doc.zip archive, or on https://gdal.org. And for man pages, "make install" does the job with the pregenerated man pages.
Thanks for pointing to the pregenerated HTML doc archive (for MS4W I still build & package Sphinx docs, but this pregenerated archive is so much easier, thanks!). I didn't realize this existed, thanks for this, very nice addition.
sebastic
commented
2 years ago So .. why not start distribute everything under one common licence or set of licences to make packagers life easier?
I'm not sure what the licensing issue is really. The license of read-the-docs is MIT (https://github.com/readthedocs/readthedocs.org/blob/main/LICENSE), and the fork of it we inherited to is also MIT: https://github.com/OSGeo/gdal/blob/master/doc/source/gdal_rtd/LICENSE
The fonts are differently licensed, e.g. miriamlibre, sintony, and sourcecodepro are OFL-1.1, but proximanova is complicated.
rouault
commented
2 years ago just checked what I have in my set of patches against gdal:
The patches against .c files are no longer needed with GDAL 3.5.0/master as far as I can see, and we no longer maintain older branches. The ones in autoconf/GNUmakefile are not going to be useful as we're going to remove it in master in a few weeks
instead hardcoding all that crap
please soften your language. That "crap" is extremely useful for developers on a daily basis. If that causes issues for specific builds/purposes, then I guess a specific option could be added to disable them. That should be done for CMake builds, and the equivalent is in gdal.cmake
rouault
commented
2 years ago but proximanova is complicated.
I suppose we could switch to another font if that one is an issue. But should be a topic for another ticket, as that one becomes messy
kloczek
commented
2 years ago And yet another though. Most of the compile or link time issue would be way easier to avoid if from the beginning GNU tooling would be used with proper automake use. It means replace all GNUmakefile files with way simpler Makefile.am. Trying o move from raw autoconf + custom GNUmakefile files to cmake is like tiring to escape from fry pan to open fire .. all because you need to learn from the begging the same tricks using completely new tooling. Just in case .. I'm not complaining. I have my own solutions. I'm only trying gently point that sometimes it was really better to follow evolution instead introducing revolution.
rouault
commented
2 years ago I'm only trying gently point that sometimes it was really better to follow evolution instead introducing revolution.
The main motivation behind the switch to CMake was to have a single build system for Unix and Windows. Proper use of autoconf/automake wouldn't have solved that. A number of projects related to GDAL (PROJ, GEOS) have gone through that route.
kloczek
commented
2 years ago I suppose we could switch to another font if that one is an issue. But should be a topic for another ticket, as that one becomes messy
Sorry for that. I've lost a bit my temper .. only because I've realised that at every new release I've spend significant amount of time only to make build procedure working .. again.
And again .. IMO cmake it is kind of dead end. It looks attractive but provides nothing new compare to GNU auto tools which is now problematic only because it it poorly maintained. Someone instead reinventing the wheel should just make a fork and start fixing normal flow of new issues. At least autoconf now is ell enough maintained however to make that more robust automake and libtool needs to be maintained on the same level as autoconf.
kloczek
commented
2 years ago The main motivation behind the switch to CMake was to have a single build system for Unix and Windows.
The same can be done with GNU auto tools and meson. Problem with GNU auto tools is that because begging of that framework was on Unix systems there is no to many people which knows how to correctly use it with Windows. So it is not that that tooling was or is not ready for Windows learning that tooling for Windows developers is quite hard because there is no enough critical mass people which now how to use it on that platform.
kloczek
commented
2 years ago The same can be done with GNU auto tools and meson
And building stuff would be easy if custom GNUmakefile files where used. That was main obstacle ..
kloczek
commented
2 years ago So .. why not start distribute everything under one common licence or set of licences to make packagers life easier?
I'm not sure what the licensing issue is really. The license of read-the-docs is MIT (https://github.com/readthedocs/readthedocs.org/blob/main/LICENSE), and the fork of it we inherited to is also MIT: https://github.com/OSGeo/gdal/blob/master/doc/source/gdal_rtd/LICENSE
So .. there is no issue -> no real reason to keep documentation separated.😄
BTW: that RFC.
SWIG bindings[](https://gdal.org/development/rfc/rfc84_cmake.html#swig-bindings)
The Python, Java and CSharp bindings will be available as options of the CMake build options.Please do net keep to many eggs in one basket. python binding can be maintained as separated pypi project, perl on cpan, java .. If you are going to keep everything under one cmake hood please be aware that cmake do not support pep517 build procedure and looks like no one want to maintain that part of the cmake. All because python has its own build tooling. The same will be true with per, java, WhateverOtherLanguageBinding.
If you really want to move away from GNU auto tools please move to meson.
The move to CMake was discussed and approved many months ago: https://gdal.org/development/rfc/rfc84_cmake.html . We're not going to change from build system in the next 10 years hopefully.
If you know what will happen within next 10ys please start playing lottery 😋
10 years ago not to many people would tell you that GNU autotools is crappy 😄
gdt
commented
2 years ago I hope it's still ok to be on-topic with this ticket :-)
pkgsrc has not been packaging docs so I didn't notice the withdrawal.
pkgsrc doesn't end up with man pages. That's a bug. I am still using autoconf (because 3.4 did, and I haven't gotten to changing the package, which I view as something I need to do before I update to 3.6).
In general, I think people should be able to get sources for docs and build them, even if there are pregenerated files. I am fine with the release process having gdal-docs-src next to gdal as a tarball, assuming once can treat that like a normal package and build docs with configure/make/make install (in 3.5) or "mkdir build; cd build; cmake .." (in 3.5 and 3.6+). I am also totally fine with a docs dir in the main tarball, where one builds it by "cd docs" and then one of the above. That avoids split versioning and an extra file, with a an extra cd. In general I like things that are splittable being split rather than build options, so we can straightforwardly build just gdal code (and install man pages) in one package and then have docs with doc dependencies with another. Unlike Debian with split packages AIUI, in pkgsrc it's not ok to make the main build depend on the union of dependencies, as we few users building from source, including on low-resource machines, as normal.
eli-schwartz
commented
2 years ago please soften your language. That "crap" is extremely useful for developers on a daily basis. If that causes issues for specific builds/purposes, then I guess a specific option could be added to disable them. That should be done for CMake builds, and the equivalent is in gdal.cmake
In general, it's considered a code smell for -Werror to be embedded inside a build system, whether that is done in autotools, cmake, or meson is pretty irrelevant.
As a developer tool and for enforcing CI checks, I agree it's extremely useful. The problem really is when ordinary distributors get -Werror in stable release builds, as that can lead to "the distro updated the compiler, GCC added new default warnings, now unrelated packages fail during the mass rebuilds for poppler or perl or whatever". Stable release packages failing in mass rebuilds is a bit of a painful experience, though hopefully one we can all remain calm about.
So, options (and best of all, standardized options) are the best of both worlds IMO.
Meson does include a builtin core option meson setup -Dwerror=true to toggle it on/off, which is useful as a convention (so people don't need to go hunting down options per software project) but of course an option can be manually added in cmake too.
It is... probably not remotely worth porting the entire project from cmake to Meson just to take advantage of Meson's builtin werror configure option, especially if you've already considered it and rejected it because despite meson generally scoring well on the same list of requirements, it simply wasn't familiar to active contributors, and that's pretty important too...
Problem with GNU auto tools is that because begging of that framework was on Unix systems there is no to many people which knows how to correctly use it with Windows. So it is not that that tooling was or is not ready for Windows learning that tooling for Windows developers is quite hard because there is no enough critical mass people which now how to use it on that platform.
The problem is also that autotools on Windows basically requires building from a mingw/msys/cygwin shell after installing a ton of stuff just to appease autotools, and it's a significantly awkward experience, really slow because shell script build systems rely heavily on forking which has steep penalties on Windows, etc. So while it's technically possible, in practice the Windows world is divided into two groups:
rouault
commented
2 years ago it's considered a code smell for
-Werrorto be embedded inside a build system
just to correct facts: -Werror is not set by GDAL's autoconf/CMake scripts. They only enable warning switches that are detected to be supported by the compiler.
eli-schwartz
commented
2 years ago Well then, I confess I don't quite understand why anyone would care about that. Warning flags don't remotely hinder @kloczek's ability to build a package, they just add some additional log lines and...
... most warnings other than -Wextra don't even change from compiler release to release, so once they are fixed once they are fixed forever. There is zero reason to ever remove those once a policy is enforced and successfully met!
I found -Werror mentioned in a cursory look at that patch listed above, but wasn't entirely sure how it was being used, two instances seem to be commented out and another couple instances I guess may only be getting used inside compiler checks? I guess I misread.
rouault
commented
2 years ago I guess may only be getting used inside compiler checks?
yes. Actually the following is enabled "-Wformat -Werror=format-security -Wno-format-nonliteral", but that's not plain -Werror.
kloczek
commented
2 years ago "mkdir build; cd build; cmake ..
This can be shortened to cmake build. Than cmake --build build.
With that it doesn't matter which one cmake backend will be used (make or ninja) and all will be still working/transparent.
Well then, I confess I don't quite understand why anyone would care about that. Warning flags don't remotely hinder @kloczek's ability to build a package, they just add some additional log lines and...
... most warnings other than -Wextra don't even change from compiler release to release, so once they are fixed once they are fixed forever. There is zero reason to ever remove those once a policy is enforced and successfully met!
Exactly!!! You nailed that and this is only simplest use case.
More complicated is injecting int to kind of para-build CC=<C_code_analuyser> CXX=<C++_code_analyser cmake build <cmake_options> ; cmake --build build.
This is why those warning flags should be always injected over CFLAGS="-Wfoo -Wbar" cmake build.
Detecting availability of those flags is just waste of time and waste of disk space on every possible build system if logs are stored. You can imagine how much disk space have been wasted on that only because all that "warningology" is hardcoded in original source tree.
As exact project developer you always will know which one compiler you are going to use and if it will be used more than one in more than one test builds always it is possible to inject different set of flags .. all WITHOUT TOUCIHING ANYTHONG in source tree!!! All that kind of alteration can be and should be done on layer above like CI or build infrastructure used in exact OS distribution. The same is with optimisation flags of linking flags. All those bits should be transparent/empty
Let me show you something:
[tkloczko@devel-g2v SPECS]$ grep "^Patch.*%{name}-remove_hardcoding_compiler_warning_flags.patch" *spec | wc -l; ls -1 *spec | wc -l
122
4171So this means that I have already +120 similar patches like for gdal and this is only bagging because according to my estimations using already produced build logs for those +4.1k packages number of such packages with that kind of patches will be around 1.4k. And yes .. as I've mentioned I've already added such patch for gdal (to part of my gdal.spec file)
Summary: GIS file format library
Name: gdal
Version: 3.5.0
Release: 4%{?dist}
License: MIT (https://opensource.org/licenses/MIT/)
URL: https://www.gdal.org/
VCS: https://github.com/OSGeo/gdal/
Source0: %{VCS}/releases/download/v%{version}/%{name}-%{version}.tar.gz
Source1: https://download.osgeo.org/gdal/%{version}/%{name}autotest-%{version}.tar.gz
Patch: %{name}-java.patch
#Patch: %{name}-tirpcinc.patch
Patch: %{name}-iso8211.patch
Patch: %{name}-installapps.patch
Patch: %{name}-gcc11.patch
Patch: %{name}-no-diag-disable.patch
Patch: %{name}-autoconf270.patch
Patch: %{name}-remove_multiple_PKG_PROG_PKG_CONFIG.patch
Patch: %{name}-remove_hardcoding_compiler_warning_flags.patchSo .. feel free to use that patch or just tell me to submit that as. I would recommend to merge that after reshape CI to use env variables to inject exact warning flags.
eli-schwartz
commented
2 years ago More complicated is injecting int to kind of para-build
CC=<C_code_analuyser> CXX=<C++_code_analyser cmake build <cmake_options> ; cmake --build build.
So you're using a not-compiler that doesn't wrap and ignore common compiler flags, which it probably should.
I don't think it makes sense to remove any compiler flags based on "a code analyzer used as a $CC replacement doesn't understand it".
If anything, those flags should be set via if/else blocks based on cmake check_cxx_compiler_flag(-Wflag RET) -> if (RET) -> add_compile_options (or meson c_args = compiler.get_supported_arguments(['-Wflag', '-Wotherflag']), or autotools AX_CHECK_COMPILE_FLAG([-Wflag],,, [-Wflag], )) and then it is the responsibility of your code analyzer to behave sensibly when doing such a compile check. In fact, your listed patch is deleting a whole lot of AX_CHECK_COMPILE_FLAG already, and gdal.cmake contains quite a bit more for the new build system.
Sounds to me like your code analyzer is broken.
kloczek
commented
2 years ago So you're using a not-compiler that doesn't wrap and ignore common compiler flags, which it probably should.
Why it should be doing that if on many projects which are not trying to solve famine problem on Earth using build framework ItJustWorks™️? 🤔
eli-schwartz
commented
2 years ago Why it should be doing that if on many projects which are not trying to solve famine problem on Earth using build framework ItJustWorkstm? thinking
Because many projects which are not trying to solve "something meant to sound mocking and insulting", do use -W flags and it doesn't "just work" if your not-compiler doesn't implement a compiler-like interface when being used as a drop-in for one.
Also because it's more broken than just not wrapping and ignoring those flags. Apparently compiler checks succeed and report those flags are supported with your not-compiler, but then fail when compiling source code instead of compiler check snippets. There's an obvious inconsistency here.
Also, your not-compiler should not be getting used when
Trying to update my gdal rpm package
because updating an rpm package means building executables and libraries, not running a code analyzer instead, so obviously something more fishy than usual is going on here.
kloczek
commented
2 years ago because updating an rpm package means building executables and libraries, not running a code analyzer instead, so obviously something more fishy than usual is going on here.
Really sorry but you are so wrong .. rpm spec file contains build procedure description. That procedure as platform is highly parametrized because it does not contain literal sequences of commands but macros. Altering content of those macros is possible to used that procedure for maaaany other things than only build package. For example %cmake macro in my case looks like below
%cmake %{set_build_flags} \
%__cmake \\\
-B %{_vpath_builddir} \\\
-D BUILD_SHARED_LIBS=ON \\\
-D CMAKE_AR="$AR" \\\
-D CMAKE_BUILD_TYPE=RelWithDebInfo \\\
-D CMAKE_C_FLAGS_RELEASE="-DNDEBUG" \\\
-D CMAKE_CXX_FLAGS_RELEASE="-DNDEBUG" \\\
-D CMAKE_Fortran_FLAGS_RELEASE="-DNDEBUG" \\\
-D CMAKE_INSTALL_PREFIX=%{_prefix} \\\
-D CMAKE_NM="$NM" \\\
-D CMAKE_RANLIB="$RANLIB" \\\
-D CMAKE_VERBOSE_MAKEFILE=ON \\\
-D INCLUDE_INSTALL_DIR=%{_includedir} \\\
-D LIB_INSTALL_DIR=%{_libdir} \\\
%if "%{?_lib}" == "lib64" \
-D LIB_SUFFIX=64 \\\
%endif \
-D SHARE_INSTALL_PREFIX=%{_datadir} \\\
-D SYSCONF_INSTALL_DIR=%{_sysconfdir} \\\
-S %{_vpath_srcdir}On top you can find %{set_build_flags}. That macro in my case looks like below
%set_build_flags \
CFLAGS="%{build_cflags}"; \
CXXFLAGS="%{build_cxxflags}"; \
FFLAGS="%{build_fflags}"; \
FCFLAGS="%{build_fflags}"; \
LDFLAGS="%{build_ldflags}"; \
CC="%{__cc}"; CXX="%{__cxx}"; FC="%{__fc}"; \
AR="%{__ar}"; NM="%{__nm}"; RANLIB="%{__ranlib}"; \
export CFLAGS CXXFLAGS FFLAGS FCFLAGS LDFLAGS CC CXX FC AR NM RANLIB; \
%{nil}Using above is possible to run rpmbuild -bc -D "__cc <code_analyser>" gdal.spec to perform code analyse. As you see all that can be done without changing even single line in the spec file. and without producing packages (-bc is for only perform %prep and %build and noting more).
Another example. In +97% of my python-*.spec files I have in %check section %pytest macro by redefine over command line that macro I can pass to pytest for example --cov or --black to perform additional audit of the whole source tree code using those pytest extensions.
Going back to the topic. So what will happen wit documentation? 🤔 IMO splitting gdal tree into multiple dist tar balls is nothing more than just adding another bits of complexity creating more problems/changes for people like me.
Are you interested any of the patches which I've copied here?
eli-schwartz
commented
2 years ago because updating an rpm package means building executables and libraries
Altering content of those macros is possible to used that procedure for maaaany other things than only build package.
I'm aware that rpm uses macros. I simply disagree that you are updating a package if you're doing one of these "many" other things than "only build package".
If you're not building a package, and in fact aren't building the project at all, I don't think it is any project's responsibility, including gdal, to guarantee that it will work. It is YOUR responsibility to make your code analyzer work.
Another example. In +97% of my python-*.spec files I have in %check section
%pytestmacro by redefine over command line that macro I can pass to pytest for example--covor--blackto perform additional audit of the whole source tree code using those pytest extensions.
Why does a distro need to "audit" whether projects use a coding style with single quotes or double quotes? In fact, why does anyone? What are you going to do, submit a bug report that you think they'd be better off switching to double quotes?
Do you report bugs to python projects if their testsuites don't support pytest and cannot run black via rpm macro redefinition?
So what will happen wit documentation? thinking IMO splitting gdal tree into multiple dist tar balls is nothing more than just adding another bits of complexity creating more problems/changes for people like me.
Personally, I think separate dist tarballs makes a lot of sense. Many distros don't necessarily want to distribute HTML documentation (it's not exactly integrated into the system the way man pages are), and many other distros DO want to distribute it, but only as a separate optional package.
Multiple dist tarballs is a clear and obvious win for the "separate optional package" workflow.
kloczek
commented
2 years ago I'm aware that rpm uses macros. I simply disagree that you are updating a package if you're doing one of these "many" other things than "only build package".
If you are thinking that people are doing such things manually .. yes you are right. You are only thinking that it is true. Maybe it is not obvious but people working on OS distributions have it own tooling consisting from tons of automations.
Why does a distro need to "audit" whether projects use a coding style with single quotes or double quotes? In fact, why does anyone? What are you going to do, submit a bug report that you think they'd be better off switching to double quotes?
Because bad things happens and we are dealing only with not enough well tested code. As long as you are probably been working only with handful source code projects it it obvious that you are not aware what is possible to find working with Sandsend's.
Personally, I think separate dist tarballs makes a lot of sense. Many distros don't necessarily want to distribute HTML documentation (it's not exactly integrated into the system the way man pages are), and many other distros DO want to distribute it, but only as a separate optional package.
Many? How many? Please focus on gdal issue and do not try to solve problems outside that area. cmake and GNU auto tools provides targets to generate dist tar balls. If you are going to not use those procedures it means that you do not understand hose tools and most likely you are going to use them wrongly wasting you preciouses time on anticipate what other people may do with result of your work. I can guarantee that strength of the set of such possibilities is continuum. (infinity). Please focus on simples possible solation .. KISS.
Do you report bugs to python projects if their testsuites don't support pytest and cannot run black via rpm macro redefinition?
In last +1.5y usually at least one tame each day. Just check my github activity.
Many distros don't necessarily want to distribute HTML documentation (it's not exactly integrated into the system the way man pages are), and many other distros DO want to distribute it, but only as a separate optional package.
Many? How many? Again .. if package A is build part of the build process is actually build and package documentation. Try to have look around. Try to find how many packages in Fedora or Debian builds documentation and main package separately. Maybe this will give you some clue ..
Currently gdal has two tar balls. First one with code and second one with test suite data. Even that split is pointless ..
jratike80
commented
2 years ago Should we make a conclusion? I am GDAL user who knows nothing about builds and coding so I can only say that the discussion has been somewhat interesting to follow but I think that it the could have been possible to tell the same message with more kind language.
If I understand right, the concrete suggestion it to have code and docs in one tarball while now they are in two. Both options have supporters and I believe that like it tends to be in life, both options have pros and cons. The solution will be either-or because I guess a compromise solution to have one and a half tar balls is not possible. So what to do?
kloczek
commented
1 year ago Any progress on thi sPR? 🤔 If you don't like it please close it without merge.
rouault
commented
1 year ago Any progress on thi sPR? thinking. If you don't like it please close it without merge.
(technically this is just an issue, not a pull request, so there's nothing to "merge")
But terminology aside, indeed closing this issue, as for now we'll stick with the current status quo
Trying to update my gdal rpm package I found that acter pass autoconf I cannot do
make manLooks like
doc/directory is no longer included in dist tar ball 🤔