1) Set the following definitions in adition to setting CMAKE_INSTALL_PREFIX:
cmake -DCMAKE_C_FLAGS:STRING="${CFLAGS} ${CPPFLAGS}" \
-DCMAKE_CXX_FLAGS:STRING="${CXXFLAGS} ${CPPFLAGS}" \
-DCMAKE_EXE_LINKER_FLAGS:STRING="${LDFLAGS}" \
-DCMAKE_SHARED_LINKER_FLAGS:STRING="${LDFLAGS}"
2) Do not set CMAKE_BUILD_TYPE, as it may add options that overide those in makepkg.conf.
3) If the PKGBUILD performs an out of source build, which is highly recommended by the cmake authors, the build directory should be a subdirectory of the source directory so that "makepkg -C" still works as intended.
]]>You can't keep the timesaving of incrememental builds and apply changes from makepkg.conf. For those changes to apply, you need to rebuild.
In fact, if you change your makepkg.conf build flags, then do an incrememental build with the new flags, you could very likely cause significant breakage as different modules would be build with different build flags. In such cases, the options of rebuild the whole package, or keep the original buildflags are the only sane options.
Which is why it is nice that cmake does recreate everything that is affected by those flags.
Things that don't get rebuilt: automoc, translations, rcc...
So still a timesaver.
...
But if it didn't know to rebuild everything that depended on those flags, I expect I would realize when things failed to compile.
I know I didn't remember to do a cleanbuild for at least one package when the C++ ABI thing happened, and the large error messages during the build made it clear enough.
In fact, if you change your makepkg.conf build flags, then do an incrememental build with the new flags, you could very likely cause significant breakage as different modules would be build with different build flags. In such cases, the options of rebuild the whole package, or keep the original buildflags are the only sane options.
]]>A related issue is that cmake does not in any way use CPPFLAGS, so for a package to use this variable from makepkg.conf the PKGBUILD must explicitly add CPPFLAGS to both CMAKE_C_FLAGS and CMAKE_CXX_FLAGS. So currently the default value of '-D_FORTIFY_SOURCE=2' in makepkg.conf is being ignored by any package using cmake that does not explicitly do this.
]]>Can you clarify what problem this would solve? If there is a PKGBUILD that calls cmake twice, the much easier fix would be to remove the redundant (and apparently problematic) call to cmake.
If any guidance should be added to the wiki, it should be information on the proper use of cmake - not how to get away with using it improperly.
How about... any time you rerun makepkg?
I don't usually bother to use `makepkg -C`, especially not when dealing with a *-git package... I like my timesaving incremental builds.
In fact, the only package I currently build from the AUR that uses cmake, is sigil-git.
So presumably, if it didn't already include these, I might find that changing the makepkg.conf flags had no effect. And not even realize it until much later (if ever).
]]>If any guidance should be added to the wiki, it should be information on the proper use of cmake - not how to get away with using it improperly.
]]>On the other hand, this will always pass the current $CFLAGS into cmake, and force a full rebuild if necessary.
cmake -DCMAKE_C_FLAGS:STRING="${CFLAGS}" -DCMAKE_CXX_FLAGS:STRING="${CXXFLAGS}" /path/to/src
repeated invocations of makepkg should always rerun cmake...
Agreed, if the PKGBUILD is written as you suggest the behavior will be correct. Also, it seems LDFLAGS should be propagated to CMAKE_EXE_LINKER_FLAGS and CMAKE_SHARED_LINKER_FLAGS.
Perhaps such guidance should be added to the wiki?
]]>On the other hand, this will always pass the current $CFLAGS into cmake, and force a full rebuild if necessary.
cmake -DCMAKE_C_FLAGS:STRING="${CFLAGS}" -DCMAKE_CXX_FLAGS:STRING="${CXXFLAGS}" /path/to/src
repeated invocations of makepkg should always rerun cmake...
...
Now, perhaps it could be argued that cmake should do this automatically, rather than sticking with the old value. But clearly you can get cmake to respect $CFLAGS just fine.
So what we really need is better education for packagers of cmake projects, or (:lol:) maybe do as some other distros do and provide our own wrappers for configure, make, cmake, etc.
]]># Works
$ CFLAGS="-D MYVAR" cmake /path/to/src/dir
$ make
# Does not work
$ cmake /path/to/src/dir
$ CFLAGS="-D MYVAR" cmake /path/to/src/dir
$ make
# Does not work
$ cmake /path/to/src/dir
$ CFLAGS="-D MYVAR" make
This is to prevent broken partial rebuilds when compiler flags that affect the ABI are changed.
So in a clean build directory these environment variables will be respected. However, if you build the package, change the flags in makepkg.conf and rebuild the package then the changes to makepkg.conf will not be reflected in the new package. Deleting CMakeCache.txt from the build directory will cause the environment variables to be re-sampled and a full rebuild to be performed.
edit: removed erroneous cmake linker flag variable name
]]>The ones you're proposing are not.
I know this.
I brought it up because I don't think upstream packagers can be relied on to make the changes to fix so many broken packages.
It seems like common practice to ignore the particulars of how cmake scripts get packages built, or perhaps cmake scripts are so complex that it is common to be unaware that they are broken (in this way, since it often does not break compile).
I think it would be simpler to work around it in makepkg.conf, if that kind of thing were possible.
It's not that important to me if it gets implemented.
I'm comfortable having less problems all by myself.
]]>It doesn't execute make but it does everything autogen and/or configure would do...
IE, generate Makefile. Like I said.
CFLAGS, CXXFLAGS, and LDFLAGS are "make" variables, so they are pretty universal. The ones you're proposing are not.
]]>you are not reading any of my replies
This is what I said about your reply, after I read it:
Another valid proposal.
Again, no, it doesn't.
It doesn't execute make but it does everything autogen and/or configure would do, only much worse. I guess I mean to say its a frontend / replacement for automake.
]]>Scimmia wrote:No, it's not a front-end, either. It's a way to generate Makefiles.
It generates makefiles and build scripts and also executes them....
Again, no, it doesn't.
]]>I'd say makepkg should work with any properly used major build system.
The variables included are those necessary to make build systems work the way their authors intended them to work. Variables are not included to compensate for the misuse of build systems. I'm getting the feeling you are not reading any of my replies, so I don't think I'll post any more.
]]>OK. Then report it as a packaging but to that packages upstream source, or the AUR packager.
Another valid proposal.
I'm curious, how did we settle on the variables specified on makepkg.conf as they are?
There must be some line between a flag that fixes lots of packages but can't be expected to be included by packagers and a flag so obvious not including it should be reported as a bug.