Package Details: ignition-cmake 2.12.1-3

Git Clone URL: (read-only, click to copy)
Package Base: ignition-cmake
Description: Provides modules that are used to find dependencies of ignition projects and generate cmake targets for consumers of ignition projects to link against.
Upstream URL:
Licenses: Apache
Submitter: racko
Maintainer: acxz
Last Packager: acxz
Votes: 2
Popularity: 0.000355
First Submitted: 2018-02-24 09:35 (UTC)
Last Updated: 2022-05-08 19:21 (UTC)

Pinned Comments

acxz commented on 2022-05-09 16:16 (UTC)

Development is on Github: Please open issues and PRs there instead of commenting.

Latest Comments

acxz commented on 2022-05-09 16:16 (UTC)

Development is on Github: Please open issues and PRs there instead of commenting.

acxz commented on 2022-05-08 19:21 (UTC)

The urls have also been updated.

AchmadFathoni commented on 2022-05-08 12:32 (UTC)

Thanks drr21. Now it's fixed

drr21 commented on 2022-05-08 12:19 (UTC)

Package is broken. Somehow now the name of the downloaded folder starts with gz-make-ignitioninstead of ign-cmake-ignition

MaEtUgR commented on 2019-10-25 10:09 (UTC)

Thanks for the insight! Now I understand it a lot better. I saw you already had a discussion with the gazebo maintainer about requirement versioning... Let's see what happens. Since it now builds out of the box I'm super happy. Thanks and happy coding.

acxz commented on 2019-10-25 05:00 (UTC)

I see, yes --noconfirm is definitely convenient and useful.

I am not sure how yay decides on the priority of packages, but I believe it will match the package name letter for letter first, which means if gazebo requests ignition-cmake, yay gives you ignition-cmake before any other version of it. This is expected and welcome behavior, tho.

The only way to resolve this issue so that users do not accidentally download the wrong ignition-cmake version is to manually require ignition-cmake=0 in the gazebo PKGBUILD. This will also fix the issue occurring when using --noconfirm.

The reason this dependency issue is getting covered up is because there is another dependency that gazebo requires which installs ignition-cmake-0 so gazebo does not end up griping about the wrong ignition-cmake version. Basically, gazebo is installing extraneous packages that are not needed.

MaEtUgR commented on 2019-10-25 04:50 (UTC)

I believe --noconfirm is hiding the issue for you.

I only use it to verify that it's scriptable, easily repeatable, also works in docker.

and ignition-cmake-0, the latter of which is the correct one to compile gazebo with.

Then it should be the default right? Otherwise every noob user like me will do the wrong thing.

acxz commented on 2019-10-25 04:45 (UTC)

I believe --noconfirm is hiding the issue for you. If you do not use that flag, you will be given the option to choose between this package and ignition-cmake-0, the latter of which is the correct one to compile gazebo with. But yes I agree with you that the issue needs to be resolved in the gazebo PKGBUILD.

MaEtUgR commented on 2019-10-25 02:58 (UTC) (edited on 2019-10-25 03:01 (UTC) by MaEtUgR)

You seem to have this notion that this package is required for gazebo

Yes because if I install gazebo using yay -S gazebo --noconfirm the operation fails if ignition-cmake cannot be built and installed. I don't know the internals and I understood your comment before but the dependency seems to be configured somewhere.

EDIT: The PKGBUILD file of the gazebo AUR contains the line makedepends=('cmake' 'doxygen' 'ignition-cmake') I'll add a comment there to consider removing the dependency.

acxz commented on 2019-10-23 15:20 (UTC) (edited on 2019-10-23 15:21 (UTC) by acxz)

@MaEtUgR, nice! That is good to hear.

I do want to reiterate that this package is not required for gazebo. You seem to have this notion that this package is required for gazebo on ArchLinux. It is not, however. The correct package for gazebo is ignition-cmake-0.

MaEtUgR commented on 2019-10-23 14:50 (UTC)

@acxz Thanks a lot!! It fixed the problem I was seeing for ignition-cmake and for gazebo they build fine now on a fresh Manjaro machine and hence I could get rid of my ugly workaround I had. Here's btw the use case JFYI

acxz commented on 2019-10-18 07:17 (UTC) (edited on 2019-10-18 07:57 (UTC) by acxz)

Hey @MaEtUgR can you post your build output in a gist or pastebin? It would help me figure out the best solution for the problem.

EDIT: NVM, I was able to reproduce your results (I didn't have cppcheck installed so the unit testing wasn't being triggered) Added the appropriate flag to fix building, let me know if you still have troubles installing it.

Here is the relevant upstream issue:

Also as a side this package is not needed for the installation of gazebo. See:

MaEtUgR commented on 2019-10-17 09:53 (UTC)

I have the same issue that was already reported before and also posted my workaround when installing gazebo on Manjaro here:

Especially the part

Would be nice if the root cause could actually get fixed since the ignition-cmake PKGBUILD defines ENABLE_TESTS_COMPILATION:BOOL=False and then CMake out put tells you that parameter doesn't exist but you need to disable testing (which ENABLE_TESTS_COMPILATION:BOOL=False previously probably did) to make the build work on Arch.

Is probably something that could be added in this AUR to solve the problem. Or did I understand it wrong?

tomcattiger commented on 2019-08-07 14:13 (UTC)

@joaocandre if you'd met this problem because of installing of ROS, you can choose ignition-xxx-1 (usually the second choice).

acxz commented on 2019-07-21 18:23 (UTC) (edited on 2019-07-21 18:24 (UTC) by acxz)

@joaocandre I am afraid I do not know the solution to your issue. Can I ask why you want to use ignition-cmake? If it is for gazebo, ignition-cmake-0 is needed rather than the latest ignition-cmake.

joaocandre commented on 2019-07-21 17:50 (UTC)

@acxz done that (, but hasn't helped much though. Is this seriously only happening with me? I don't think there is anything wrong with python configuration at least, can't understand what's happening.

acxz commented on 2019-07-06 00:36 (UTC)

hmm @joaocandre that is weird, the build works fine on my machine. I suggest you create an upstream issue at

joaocandre commented on 2019-07-05 20:00 (UTC)

Compilation failing with

[ 15%] Performing codecheck step for 'core_no_deps_Debug'
Scanning dependencies of target codecheck
make[6]: *** [CMakeFiles/codecheck.dir/build.make:59: CMakeFiles/codecheck] Error 1
make[5]: *** [CMakeFiles/Makefile2:142: CMakeFiles/codecheck.dir/all] Error 2
make[4]: *** [CMakeFiles/Makefile2:149: CMakeFiles/codecheck.dir/rule] Error 2
make[3]: *** [Makefile:201: codecheck] Error 2
make[2]: *** [examples/CMakeFiles/core_no_deps_Debug.dir/build.make:124: examples/core_no_deps_Debug-prefix/src/core_no_deps_Debug-stamp/core_no_deps_Debug-codecheck] Error 2
make[1]: *** [CMakeFiles/Makefile2:1232: examples/CMakeFiles/core_no_deps_Debug.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
==> ERROR: A failure occurred in build().

acxz commented on 2019-06-30 21:22 (UTC) (edited on 2019-06-30 21:56 (UTC) by acxz)

Ah pardon my ignorance, thank you for enlightening me!

EDIT: Fixed!

portaloffreedom commented on 2019-06-30 20:57 (UTC) (edited on 2019-06-30 20:58 (UTC) by portaloffreedom)

Could you please remove the -j4 option in make for all ignition packages? It overrides the default in my machine, where I have 8 cores... Users can achieve parallel compilation by editing the /etc/makepkg.conf and setting the MAKEFLAGS variable accordingly

Thanks :)

acxz commented on 2019-06-27 23:08 (UTC)


acxz commented on 2019-06-11 21:01 (UTC)

Can this package be updated?

FabioLolix commented on 2018-02-24 12:36 (UTC) (edited on 2018-02-24 12:51 (UTC) by FabioLolix)

@racko I see there are several red marked dependencies for gazebo but at least ignition-common, ignition-math and ignition-cmake install with yaourt; maybe is a temporary aur webpages quirks.

If naming scheme is far from ideal in source or other places don't mean must be replicated here :)

Issues are not related

racko commented on 2018-02-24 12:18 (UTC)

Does anybody have an idea why the ignition-cmake dependency is colored red on It usually it means that a dependency is missing, but clearly exists.

@FabioLolix: The two issues are not related, are they? I don't plan to rename this package because that's the name it has everywhere else:,

FabioLolix commented on 2018-02-24 10:09 (UTC)

I guess the right name for this package is cmake-modules-ignition :)