Arch Linux User Repository

Hi everyone, thanks for your response. However, I would like to make a few things clear:

• While it's true that my intention is to stay aligned to the upstream but, now that the they adopted CMake, I couldn't see the reason anymore to not allow users some flexibility on how they build the package. Unfortunately it appears now that this isn't always possible, and I won't try to accomodate everyone at any cost.

• The 'complicated additional options' has nothing to do with CMake's build type, but rather they were a workaround to an issue I have had with how CMake typically handles CFLAGS/CXXFLAGS (they are only passed and stored once, at the configuration time). In any case I have already said I'll remove them soon, along with MAKEFLAGS and ccache option, so that's the end of this discussion.

• I didn't see any issues with RelWithDebInfo which sets -O2 and not -O3, this is what it counts. However I'll change it to None soon as recommended, but I should point out that it won't make much difference, as the aforementioned flag was already overrideable by CFLAGS/CXXFLAGS before. And then there's the fact that even with None it will still append a lot of other flags to the compiler, and these ones aren't overrideable per upstream's decision.

• Before anyone asks about building with gcc, there are some known issues that need to be resolved before I can lift off clang/lld requirements though they are the upstream project's recommended way.

TLDR: Set whatever build type you want, but get rid of the extraneous options.

Using None is not required, but recommended. That is why I say one should set it that way. The reason, described in the guideline, is that upstream projects generally modify build flags for the other build types, which can cause problems when users (devtools) set their own flags. The problems the maintainer appears to be trying to work around would likely be solved by setting build type to None, as recommended by the guidelines.

However, the maintainer may cite upstream intention as a reason to not use None. In that case, the extraneous options should still not be used because they override upstream intention.

I have read about the CMake package guidelines. It seems that nowhere it's written that one must set -D CMAKE_BUILD_TYPE=None

https://wiki.archlinux.org/title/CMake_package_guidelines

2.1.2 Fixing the automatic optimization flag override
[...]
The default CMake build type is None and it does not append any flags to CFLAGS and CXXFLAGS by default

Hi xiota, I have read about the CMake package guidelines. It seems that nowhere it's written that one must set -D CMAKE_BUILD_TYPE=None regardless, just that its use is recommended to avoid that unwanted -O3 optimization flag that would be set automatically with CMAKE_BUILD_TYPE=Release. In this case, though, it's the build type RelWithDebInfo that is being used here and that it sets -O2 not -O3, this is what the upstream uses by default anyways. Don't you agree?

However, I will simplify the PKGBUILD as per request, removing the options for CFLAGS and company (despite the reason stated before for putting them in first instance). I'll remove MAKEFLAGS too, looks like it's impossible to make everyone happy...This applies the same to ccache too, at this point if one doesn't want to use ccache then this should be uninstalled, in any case it shouldn't be a problem for CMake.

Since there appears to be confusion about appropriate cmake flags, see CMake package guidelines.

Practically, only the following, plus app specific flags, are needed in most cases:

  -B build
  -S source
  -D CMAKE_BUILD_TYPE=None
  -D CMAKE_INSTALL_PREFIX=/usr
  -W no-dev

CMake uses environment variables automatically. So redundant to set cmake-specific flags for CC, CXX, CFLAGS, CXXFLAGS, LDFLAGS, etc. Only change the ones that are really need. Also, don't try to extract specific flags from MAKEFLAGS, and don't try to change ccache settings. They should "just work".

CMAKE_BUILD_TYPE should be set to None whenever possible. Not doing so may be the cause of whatever issues the maintainer is trying to work around.

Thank you, I have updated the PKGBUILD accordingly. It should be okay now. Should CFLAGS and other flags start to give issues, I'll take care of them too.

Ninja doesn't support all the possible MAKEFLAGS. For example, it will cause problem if I use gnu make job server that will fill MAKEFLAGS with stuff that ninja doesn't understand.

As for the flags, it doesn't hurt, however note that only full clean build is supported.

For ccache, DENABLE_CCACHE=OFF will turn off ccache use in their cmake files but will not prevent its use from makepkg.conf ccache option. That option simply add /usr/lib/ccache/bin to the PATH so any invocation of clang or gcc will use ccache transparently.

EDIT: Removed part about NINJAFLAGS, it's not standard. You could still replace MAKEFLAGS with it though or maybe try parsing MAKEFLAGS for a -j option.

Hi patlefort, thanks for your suggestions, though I have some questions first as I genuinely just want to understand:

-MAKEFLAGS, can you describe these issues with ninja, that I am not aware of? It has worked great for me, and I put it as a form of courtesy to whose people that don't appreciate the fact that ninja uses every core of the processor. The variable MAKEFLAGS gives them some form of control on the number of core to be used for building process.

-DCMAKE_C_FLAGS, DCMAKE_CXX_FLAGS and DCMAKE_EXE_LINKER_FLAGS, I agree that these variables are already inherited, though I have had some issues when rebuilding the package, specifically when I change some flags in CFLAGS in makepkg.conf for testing purposes but CMake for some reasons doesn't detect these changes. These CMake parameters apparently forces them, so I left them in place. What's the harm with leaving them in PKGBUILD if they don't cause issues?

-DENABLE_CCACHE=OFF, you're right about the forced use of ccache. I have looked at it, I have forgot that there's a variable controlling the use of ccache in makepkg.conf, so I'll remove ccache from makedepend. Though, isn't -DENABLE_CCACHE=OFF also kinda doing the same thing, but in the opposite way? Isn't it better to leave the choice to users?

Patch for this package for proposed changes: https://pastebin.com/gjhV4f0L

I also added -DENABLE_CCACHE=OFF because we don't want to force use of ccache in pkgbuilds.

Can you please remove $MAKEFLAGS statement? It's not useful and it even cause issues when ninja is used. Also, DCMAKE_C_FLAGS, DCMAKE_CXX_FLAGS and DCMAKE_EXE_LINKER_FLAGS will already inherit the env. vars. you are passing to them.