Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 369565 - dev-util/anjuta: Cannot create generic vala project if unversioned binaries are not available
Summary: dev-util/anjuta: Cannot create generic vala project if unversioned binaries a...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-31 18:48 UTC by Stephan Haller
Modified: 2011-07-07 11:00 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
vala.eselect (vala.eselect,2.46 KB, application/octet-stream)
2011-06-01 13:58 UTC, Stephan Haller
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Haller 2011-05-31 18:48:52 UTC
Vala is installed slotted. Therefore there is no binary called valac (and so on) in /usr/bin but valac-0.10 or valac-0.12. Because of this I cannot create a generic vala project using Anjuta, an IDE created for GNOME desktop environment. Even the installed and used vala.m4 macros do not help because the variable $VALAC looks for "vala" in $PATH but not for any slotted/versioned vala-0.10 or vala-0.12. Therefore the autotools determine the vala compiler as not being installed.

I would suggest to have an eselect module to set an installed version of vala as action and to create the appropiate symlinks like /usr/bin/vala -> /usr/bin/vala-0.12. If guided I would try my luck ;)

Reproducible: Always

Steps to Reproduce:
1. Start anjuta
2. Create a vala project
3. Run configure on newly create project
Actual Results:  
When running configure script you get the following messages:

[...]
checking for valac... no
configure: WARNING: No Vala compiler found.  You will not be able to compile .vala source files.
[...]

Expected Results:  
But I expect:

[...]
checking for valac... yes
[...]
Comment 1 Stephan Haller 2011-06-01 13:58:42 UTC
Created attachment 275497 [details]
vala.eselect
Comment 2 Stephan Haller 2011-06-01 13:58:53 UTC
I tried my luck and created an eselect module for vala. It is not the nicest one but it works for me. Please review.
Comment 3 Wormo (RETIRED) gentoo-dev 2011-06-01 23:01:27 UTC
An eselect module does sound like just the thing -- assigning to vala maintainers to take a look
Comment 4 Pacho Ramos gentoo-dev 2011-06-03 17:25:25 UTC
Isn't there anyway to set VALAC variable on anjuta ? (apart of running "VALAC="xx" anjuta")
Comment 5 Stephan Haller 2011-06-03 18:00:59 UTC
(In reply to comment #4)
> Isn't there anyway to set VALAC variable on anjuta ? (apart of running
> "VALAC="xx" anjuta")

I haven't found any possibility to force setting the variable VALAC. I can set flags for the vala compiler but cannot the set the path to the binary itself. I only see the m4 files which will be copied and these files look for the binary valac e.g. /usr/bin/valac. That's why a have a symlink from /usr/bin/valc-0.12 to /usr/bin/valac.

The other side is that each source file depending on vala will lookup valac in their configure script and not valac-(VERSION). I think that is one reason why - for example - media-gfx/shotwell changes "valac" to ""valac-0.10" (older version) or "valac-0.12" (current unstable version) in the Makefile with sed. Ok - the other reason is that these packages expect a minimum version of vala and DEPEND in these ebuild pull in a slotted version so you know which binary will be used ;)

In my current case with anjuta it does not help and messing up my /usr/bin by setting a symlink manually instead using a mechanism or package of Gentoo isn't as nice and not as clean as my system is at the moment :)
Comment 6 Gilles Dartiguelongue (RETIRED) gentoo-dev 2011-06-05 12:04:38 UTC
It has been said in this bugzilla before, there will be no unversioned valac symlink. It is the responsibility of packages using vala to be able to handle multiple vala installation as a system having both 0.10 and 0.12 is perfectly normal right now for example. Plus it helps to spot packages that try to use vala irrespective of the version they are actually looking for.
Comment 7 Pacho Ramos gentoo-dev 2011-06-05 12:14:55 UTC
I guess this problem should be reported to anjuta upstream, no?
Comment 8 Pacho Ramos gentoo-dev 2011-06-19 13:08:03 UTC
Stephan, please visit:
https://bugzilla.gnome.org/show_bug.cgi?id=652932
Comment 9 Stephan Haller 2011-06-19 18:46:49 UTC
(In reply to comment #8)
> Stephan, please visit:
> https://bugzilla.gnome.org/show_bug.cgi?id=652932

Thanks, Pachos. I took a look at the bug reported upstream and it looks to be "unresolvable". But I noticed the suggested workaround the set an environment variable in the configure dialog. I didn't know it is possible and I did not find out how exactly it works. I will ask upstream.

Anyway, thanks :)
Comment 10 Pacho Ramos gentoo-dev 2011-07-01 19:16:19 UTC
Finally, what are the steps to configure proper vala version to be used under anjuta? (I have never used anjuta and I am a bit lose :S)

Thanks
Comment 11 Stephan Haller 2011-07-04 21:27:51 UTC
(In reply to comment #10)
> Finally, what are the steps to configure proper vala version to be used under
> anjuta? (I have never used anjuta and I am a bit lose :S)
> 
> Thanks

I wasn't aware that it is possible. I thought environment variables must be put in front of the command to execute like

VALAC=/usr/bin/valac-0.12 ./configure --prefix=....

But anjuta does not support defining environment variables set up before running the configure script. I did not know that you could also define these kind of variable as parameter passed to the configure script like

./configure --prefix=.... 'VALAC=/usr/bin/valac-0.10'

Please notice the hyphens and the diffenrent value passed to VALAC ;) This method of defining "environment variables" is supported of anjuta and be set in the dialogue to set up parameters passed to the configure script.

To make a long story short: I wasn't aware that environment variables could be passed as command parameters as well.
Comment 12 Stephan Haller 2011-07-04 21:29:17 UTC
Even I would like the convinient way of using eselect to set the current active vala version ... I think we could close this ticket as RESOLVED?
Comment 13 Pacho Ramos gentoo-dev 2011-07-05 10:33:00 UTC
My plan was to include instructions at post installation to let people know how to configure vala when needed. Looks like the following steps are needed:
- Go to "Build" -> "Configure project"
- Add 'VALAC=/usr/bin/valac-0.10' to "Configure options"

Or it's not ok?
Comment 14 Stephan Haller 2011-07-06 20:51:18 UTC
(In reply to comment #13)
> My plan was to include instructions at post installation to let people know how
> to configure vala when needed. Looks like the following steps are needed:
> - Go to "Build" -> "Configure project"
> - Add 'VALAC=/usr/bin/valac-0.10' to "Configure options"
> 
> Or it's not ok?

Ahh ok. Sorry, I didn't get it. Yes, these the steps to define the valac binary to use. But it should be noted that the hyphens are very important. I did it wrong the first time ;)
Comment 15 Pacho Ramos gentoo-dev 2011-07-07 11:00:15 UTC
+  07 Jul 2011; Pacho Ramos <pacho@gentoo.org> anjuta-2.32.1.1.ebuild:
+  Add a message to explain people about how to create vala projects since we
+  don't provide unversioned binaries for vala (bug #369565 by Stephan Haller).
+