| View previous topic :: View next topic |
| Author |
Message |
Peach
Advocate
Joined: 08 Mar 2003
Posts: 3686
Location: London, UK
|
 Posted: Sun Jan 12, 2014 6:39 pm Post subject: CMakefile check for vapigen (vala) breaks ebuild |
 |
|
I'm trying to test some features on a dev branch of mail-client/geary.
The program (geary) depends on vala, and now it looks like it depends - explicitly - on vapigen as well as you can see from the src/CMakefile.txt content:
| Code: | # Vapigen
find_program(VAPIGEN vapigen)
if (VAPIGEN STREQUAL "VAPIGEN-NOTFOUND")
message(FATAL_ERROR "vapigen must be installed to build Geary.")
else ()
message(STATUS "Found vapigen: " ${VAPIGEN})
endif ()
|
vala is installed with vapigen USE flag enabled:
| Code: | # equery uses vala
[ Legend : U - final flag setting for installation]
[ : I - package is installed with flag ]
[ Colors : set, unset ]
* Found these USE flags for dev-lang/vala-0.22.1:
U I
- - test : Workaround to pull in packages needed to run with FEATURES=test. Portage-2.1.2
handles this internally, so don't set it in make.conf/package.use anymore
+ + vapigen : Enable vala's library binding generator
|
| Code: | # qlist vala | grep vapigen
/usr/bin/vapigen-0.22
/usr/share/man/man1/vapigen-0.22.1.bz2
/usr/share/pkgconfig/vapigen-0.22.pc
/usr/share/vala/Makefile.vapigen
/usr/share/aclocal/vapigen.m4
|
A snippet from the build process:
| Code: | >>> Working in BUILD_DIR: "/var/tmp/portage/mail-client/geary-9999/work/geary-9999_build"
cmake --no-warn-unused-cli -C /var/tmp/portage/mail-client/geary-9999/work/geary-9999_build/gentoo_common_config.cmake -G Unix Makefiles -DCMAKE_INSTALL_PREFIX=/usr -DDESKTOP_UPDATE=OFF -DGSE
TTINGS_COMPILE=OFF -DICON_UPDATE=OFF -DVALA_EXECUTABLE=/usr/bin/valac-0.22 -DWITH_UNITY=OFF -DDESKTOP_VALIDATE=OFF -DCMAKE_BUILD_TYPE=Gentoo -DCMAKE_INSTALL_DO_STRIP=OFF -DCMAKE_USER_MAKE_RUL
ES_OVERRIDE=/var/tmp/portage/mail-client/geary-9999/work/geary-9999_build/gentoo_rules.cmake /var/tmp/portage/mail-client/geary-9999/work/geary-9999
Not searching for unused variables given on the command line.
loading initial cache file /var/tmp/portage/mail-client/geary-9999/work/geary-9999_build/gentoo_common_config.cmake
-- The C compiler identification is GNU 4.7.3
-- Check for working C compiler: /usr/bin/x86_64-pc-linux-gnu-gcc
-- Check for working C compiler: /usr/bin/x86_64-pc-linux-gnu-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Found PkgConfig: /usr/bin/x86_64-pc-linux-gnu-pkg-config (found version "0.28")
-- xgettext found
-- Found Vala: /usr/bin/valac-0.22
-- checking for a minimum Vala version of 0.22.1
-- found Vala, version 0.22.1
CMake Error at src/CMakeLists.txt:404 (message):
vapigen must be installed to build Geary.
|
I wonder what would the best approach for writing the ebuild, or if it's something that needs to be fixed in the vala eclass, i.e. in what vala_src_prepare does and if it's worth a bug report.
I was thinking of going around it by adding a patch that removes that check from the CMakefile.txt and then just add a dependency on vala with vapigen use flag, but I don't know if that's correct.
_________________
Gentoo user since 2004.
"It's all fun and games, until someone loses an eye" - mom |
|
| Back to top |
|
 |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Jan 12, 2014 10:08 pm Post subject: Re: CMakefile check for vapigen (vala) breaks ebuild |
|
|
| Peach wrote: | I wonder what would the best approach for writing the ebuild, or if it's something that needs to be fixed in the vala eclass, i.e. in what vala_src_prepare does and if it's worth a bug report.
I was thinking of going around it by adding a patch that removes that check from the CMakefile.txt and then just add a dependency on vala with vapigen use flag, but I don't know if that's correct. |
The dependency is absolutely correct: if it's not mentioned as a DEPEND, then there's no reason for portage to ensure its availability at build-time.
Not sure what the actual issue is, ie why it's not finding it when you have it present; you can try #cmake on IRC:chat.freenode.net if #gentoo-gnome can't help. But the dep you propose (with the USE-flag) is correct (and may well need to be in RDEPEND too, I don't know the package.)
WRT bug-report, it's usually better to talk online first, ime, though a bugzilla search prior to that is advised. Especially if you're working on ebuilds (#gentoo-dev-help are your friends.) |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22185
|
| Posted: Sun Jan 12, 2014 10:13 pm Post subject: |
|
|
| I concur with steveL that the ebuild should have a DEPEND directive to tell Portage to install the file. Based on the provided output, the file is already installed, so Portage is installing vapigen in an unusual way or the upstream test for vapigen is wrong. Can you examine the CMake logs to tell why it thinks that vapigen is not available? Is it assuming that the program is named exactly vapigen with no suffix, unlike the versioned suffix you show? |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Jan 13, 2014 9:19 am Post subject: |
|
|
| Hu wrote: | | Is it assuming that the program is named exactly vapigen with no suffix, unlike the versioned suffix you show? |
Ah bingo, Hu, thanks. Missed that altogether. |
|
| Back to top |
|
|
Peach
Advocate
Joined: 08 Mar 2003
Posts: 3686
Location: London, UK
|
| Posted: Mon Jan 13, 2014 11:05 am Post subject: |
|
|
| Hu wrote: | | Is it assuming that the program is named exactly vapigen with no suffix, unlike the versioned suffix you show? |
CMakeOutput.log does not show anything, but given this
| Code: | # Vapigen
find_program(VAPIGEN vapigen)
if (VAPIGEN STREQUAL "VAPIGEN-NOTFOUND")
message(FATAL_ERROR "vapigen must be installed to build Geary.")
else ()
message(STATUS "Found vapigen: " ${VAPIGEN})
endif ()
|
I'm assuming you're right.
what would be the best way to move forward?
Is it something to do with the vala eclass or with the vala ebuild?
Or it's not a problem on our end and it should be reported upstream? (I'll see if anyone on #cmake can provide me a bit of clarification on this end)
_________________
Gentoo user since 2004.
"It's all fun and games, until someone loses an eye" - mom |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22185
|
| Posted: Tue Jan 14, 2014 2:52 am Post subject: |
|
|
| Assuming my suggestion is right, which seems reasonable but not confirmed yet, then this is not strictly a problem with CMake. Upstream told it to look file a file with name vapigen. CMake correctly determined that no such file existed. I do not know whether the problem is that Gentoo installed vapigen under an unexpected name or that the geary developers wrote their test incorrectly. I assume at least one distribution must ship it under the unqualified name or the geary developers would not have written their test that way. Ideally, the geary test should be modified so that the caller of cmake, in our case Portage, can tell it what name to use. With such a facility, each distribution could instruct geary to use the proper name for that distribution. |
|
| Back to top |
|
|
Peach
Advocate
Joined: 08 Mar 2003
Posts: 3686
Location: London, UK
|
| Posted: Tue Jan 14, 2014 12:22 pm Post subject: |
|
|
| Hu wrote: | | With such a facility, each distribution could instruct geary to use the proper name for that distribution. |
Good point.
Let's assume that geary devs are doing that right, and gentoo is indeed changing the name of the executable to avoid conflicts and whatever else is the reason.
Is there a way in the ebuild (as in a specific eclass to deal with such things) to extract the actual name of the executable of vapigen, e.g. to do an inline replacement in the CMakefile.txt or add a parameter for cmake?
I think this is the only trivial part.
Unless this should be something that vala_src_prepare should be doing as well (more likely not IMO).
_________________
Gentoo user since 2004.
"It's all fun and games, until someone loses an eye" - mom |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22185
|
| Posted: Wed Jan 15, 2014 3:12 am Post subject: |
|
|
I meant that there ought to be a configure option to geary where you tell it the name, rather than needing to modify their build system to force the name.
An ebuild could use has_version to determine the version of vala and then guess the name based on the version, but that would be ugly. |
|
| Back to top |
|
|
Peach
Advocate
Joined: 08 Mar 2003
Posts: 3686
Location: London, UK
|
| Posted: Wed Jan 15, 2014 11:20 am Post subject: |
|
|
| Hu wrote: | I meant that there ought to be a configure option to geary where you tell it the name, rather than needing to modify their build system to force the name.
An ebuild could use has_version to determine the version of vala and then guess the name based on the version, but that would be ugly. |
Fair enough. I'll try to raise the point with the geary devs and see what they say.
_________________
Gentoo user since 2004.
"It's all fun and games, until someone loses an eye" - mom |
|
| Back to top |
|
|
Peach
Advocate
Joined: 08 Mar 2003
Posts: 3686
Location: London, UK
|
| Posted: Thu Jan 16, 2014 3:41 pm Post subject: |
|
|
| Hu wrote: | I meant that there ought to be a configure option to geary where you tell it the name, rather than needing to modify their build system to force the name.
An ebuild could use has_version to determine the version of vala and then guess the name based on the version, but that would be ugly. |
OK, it looks like vala_src_prepare is doing something to the sandbox environment, as the current ebuild is using ${VALAC} in the src_configure to be passed to cmake.
Although even if a VALA_EXECUTABLE variable is defined in the CMakefile.txt, there isn't anything like that for the executable of vapigen.
So ideally I'd create a patch to modify the CMakefile.txt to introduce a VAPIGEN_EXECUTABLE variable, that might be pushed upstream.
Even so, I'm still at loss with the detection of the correct path of the vapigen exec installed, and the only thing seems to be your last option. Which I agree, is ugly.
Any ideas? I don't even know if that's worth a bug report to the vala maintainers about the eclass.
_________________
Gentoo user since 2004.
"It's all fun and games, until someone loses an eye" - mom |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Jan 16, 2014 5:34 pm Post subject: |
|
|
It's perfectly reasonable to look up vapigen in PATH; it also makes a lot of sense to allow the end-user/installer/distro to supply the path to use. eg ./configure .. vapigen=vapigen-22 or: vapigen=/some/path/vapigen-22. Often this is done with an env var as well; personally I'd just add VAPIGEN. Are you sure it's not already doing that? ie: have you tried to | Code: | | export VAPIGEN=vapigenXY |
before calling cmake? |
|
| Back to top |
|
|
Peach
Advocate
Joined: 08 Mar 2003
Posts: 3686
Location: London, UK
|
| Posted: Thu Jan 16, 2014 5:48 pm Post subject: |
|
|
| steveL wrote: | It's perfectly reasonable to look up vapigen in PATH; it also makes a lot of sense to allow the end-user/installer/distro to supply the path to use. eg ./configure .. vapigen=vapigen-22 or: vapigen=/some/path/vapigen-22. Often this is done with an env var as well; personally I'd just add VAPIGEN. Are you sure it's not already doing that? ie: have you tried to | Code: | | export VAPIGEN=vapigenXY |
before calling cmake? |
vapigen program name is hardcoded as far as I can see, at least in the CMakefile.txt, and I can't find anything related to vapigen in the configure script present in the root of the sources.
_________________
Gentoo user since 2004.
"It's all fun and games, until someone loses an eye" - mom |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22185
|
| Posted: Fri Jan 17, 2014 2:46 am Post subject: |
|
|
| steveL wrote: | It's perfectly reasonable to look up vapigen in PATH; it also makes a lot of sense to allow the end-user/installer/distro to supply the path to use. eg ./configure .. vapigen=vapigen-22 or: vapigen=/some/path/vapigen-22. Often this is done with an env var as well; personally I'd just add VAPIGEN. Are you sure it's not already doing that? ie: have you tried to | Code: | | export VAPIGEN=vapigenXY |
before calling cmake? |
Peach was responding to the discussion about how an ebuild run by Portage, without help from an interactive user, can determine the correct name to pass to geary. Based on findings Peach posted above, the name of vapigen seems to be dependent on the version of it that was installed. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Jan 18, 2014 11:41 am Post subject: |
|
|
| Peach wrote: | | vapigen program name is hardcoded as far as I can see, at least in the CMakefile.txt, and I can't find anything related to vapigen in the configure script present in the root of the sources. |
OK. I was hoping: find_program(VAPIGEN vapigen) meant CMake would also check if the env var were set by the user (and functional), before looking for the program under PATH.
| Hu wrote: | | Peach was responding to the discussion about how an ebuild run by Portage, without help from an interactive user, can determine the correct name to pass to geary. Based on findings Peach posted above, the name of vapigen seems to be dependent on the version of it that was installed. |
See above. Once you've got that version, eg from has_version or w/e, then I'd have hoped CMake would take the setting from the env (or indeed command-line), without requiring a patch. If not, no worries. But if it does, it's a cleaner solution. |
|
| Back to top |
|
|
Peach
Advocate
Joined: 08 Mar 2003
Posts: 3686
Location: London, UK
|
|
| Back to top |
|
|
|
Portage & Programming
