Guys, I have just created my first project and run my first make, but already discovered three easy to spot bugs at once. I must say, I am shocked.[...]
but I do hope you have some solutions or bugfixes for me.I have to say you have a strange attitude.
[...]If you post such statements, you have to live with answers like the ones from MortenMacFly.
I must say, I am shocked.
[...]
The way it is now, the software is absolutely useless, not even able to run an external makefile with a custom command without a trick (turning on full command line logging).
6. Bug reports belong in the BerliOS project page. Don't expect the devs to crawl in the forums for a bug - we're NOT Google! The bug report webpage was made for a reason.
Please don't use local attachments. Storage for the forum is limited and attachments get removed at random!
It seems that I can reproduce your bug.
Set the build command to 'xmessage -buttons "test" -center " tead" ' (build options->target->make commands->build project/target)
and then switching the log mode to something different than full log.
This is pretty strange, but calling it "quite buggy" is harsh, in fact this could be regarded as feature, because using anything that full log is asking for trouble. In fact I'll be ok/happy if we just remove the other two modes
Good to hear that calling sudo works, but what I wanted to say, is that it is not guaranteed to work in any cases.
Alternatively you can use my repo (see my sig), if the bug is fixed and I uploaded a new version.
The counting of warnings and errors works here in all cases. (...) If you use localized versions of gcc, it might break the regexes, in this case you have to fix it yourself, because we can not provide regexes for each and any probable localization. Or switch to engish, while compiling ( I have set LC_ALL to en_US.UTF-8 in my environment variables inside C::B).
about the lower- and upper case-stuff: environment-variables and user-defined fields in global variables are totally different. The later are not case-sensitive.
...I wonder how anyone could regard it a feature that custom commands are not executed with the default log options, but are with another setting...It stimulates people to use the full log. :)
Quoteabout the lower- and upper case-stuff: environment-variables and user-defined fields in global variables are totally different. The later are not case-sensitive.
Sorry to say that, but if a menu option is called "Global variables" and the dialogue title is "Global variable editor" and it even works to use a global variable as an environment variable (no matter if it is printed in lower-case when I re-open the dialogue), it is kind of counter-intuitive to assume there is a difference. I have to admit though, that if I had RTFM I probably should have known. Mea culpa. So now that I know it, I will use "Build options" - "Custom variables" which hopefully is the right place. But as it is project-specific and I wanted to set the variable for all projects once and for all, I (falsely) figured that "Global variables" was the right place. BTW, is there a way to set my variable globally for C::B (other than doing it before calling C::B, I mean).
<envvars>
<sets>
<default>
<ENVVAR0>
<str>
<![CDATA[1|SUDO_ASKPASS|/usr/lib/openssh/gnome-ssh-askpass]]>
</str>
</ENVVAR0>
</default>
</sets>
<ACTIVE_SET>
<str>
<![CDATA[default]]>
</str>
</ACTIVE_SET>
<DEBUG_LOG bool="0" />
</envvars>
Some ideas for improvement:
- If make returns with exit code 0 (zero), it would be smart to assume that there were warnings, but no errors, otherwise the exit code would be !=0.
- If you know that you only support the English version of make, maybe you could set the environment (LC_ALL or whatever is appropriate) as necessary by yourself , so you are in control of how you parse make's output. This is what my shell scripts with regexes do if I know they only work for English.
In the default.conf you attached erlier, you did not use a global variable for this, and it would not work, but you have set an environmemnt variable:
(...)
that's most likely the cause, why it works.
It's in "Settings -> Environment -> Environment variables", if the contrib-plugins-package is installed.
Talking about screenshots: In one of the screenshots above you also see the German warning ("Warnung") message you asked me to send, if you are still interested. If you ever have plans to localise the program or at least warning and error parsing, you can always run your (unit) tests for make/gcc output parsing with LANG=de_DE@euro or some UTF-8 equivalent.Unit tests? What is that? :P ::)
Maybe you could also just compare the localisation packages for the most important languages (whatever those may be, e.g. French, German, Spanish) directly to see all the relevant text strings beside each other.You're missing at least Chinese and Indian (all the variants).
@devs: have someone tried to force the locale inside the compiler plugin?I use LC_ALL in my envvars (set default).
p.s. simple export LC_MESSAGES=... doesn't work for gcc on my CentOS 5.6, which is pretty strange.
But I don't know how reliable this function works.Well shouldn't we simply assume it works reliable? What other options do we have? I don't want to implement another I18N... ;-) I like the idea and would do it this way.
As for annoying dialogues, usually it works like this: [...]C::B's annoying dialog already works like that. We just need to add the two-liner to show it, if needed.
C::B's annoying dialog already works like that. We just need to add the two-liner to show it, if needed.No need, this has been in preferences (under environment) for years.
What has been there? That you get a warning when you issue C::B under a localised environment? I don't think so. The idea here is, that in the case you run C::B under "de_DE" or alike you get an initial warning (i.e. at first startup) that using a localised compiler - which is likely in that case - may screw the regexes / output parsing. We don't have that under "environment", do we?!QuoteC::B's annoying dialog already works like that. We just need to add the two-liner to show it, if needed.No need, this has been in preferences (under environment) for years.
C::B's annoying dialog already works like that.
No matter what angle you look at it, localization is a lot of shit, both in general and in particular.
Thanks Jens. A few questions in advance because I am not a package management expert:No.
- Can I somehow install the package in parallel to the Ubuntu 11.10 one? If so, how?
I use it for my daily work,
- If not: How stable is your trunk? Depending on your SCM policy it could be stable or not.
Yes, you have to remove my repo from the sources list and most likely uninstall C::B completeley and than reinstall the ubuntu version.
- If I temporarily upgrade my installation, can I downgrade again without trouble for config and project files? If so, how do I do that?
No, I don't know on which version their package is based, but backporting it should not be too hard (it's svn r7895).
- Is the patch optionally available for the version on which the Ubuntu package is based?
Sorry for so many questions, I want to test, but not break anything here. If there is an FAQ or wiki page answering these questions already, just point me to it, please.No problem.
I translate this to "localisation should be done right and is a lot of work".I really meant to say that it's a lot of shit, but you can translate it to "does not work, adds more trouble, and besides is not done properly anywhere" if it makes you feel better. :)
Otherwise, one could as well localize C, replacing int with ganzzahl and while with während. :)That's what's done in Excel, btw. They really translated the VBA script language into other languages, too.
English is the least troublesome.You are missing one vital thing here: Unless you are a good native English speaker, you'll fail with that approach, too because you'll certainly translate wrong some times which will also be hard to understand. But I agree that nothing is worse than English from non-native-speaker translated into another language (and maybe back).
But, this is just my opinion, and I very much realize that I'm probably alone in the world. Same for smartphones and tablet PCs, and Kindle. And goatees, and tattoos. O tempora, o mores.