Custom make commands are never executed

[Jenna]

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.

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).

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:

Code

       <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>

that's most likely the cause, why it works.
It's in "Settings -> Environment -> Environment variables", if the contrib-plugins-package is installed.

The make command not working as expected is not really a bug, but a design flaw, that's near a bug, because it's really not intuitive.
When I reworked the makefile stuff some years ago, I decided to use a special command for silent output (just show tasks or no output at all), it's in the last text-control on the make-commands tab.
I can't remember why I did it that way, but I will change it and use the same command like for full commandline logging and pipe the standard output against /dev/null (or nul on windows). If that works as expected, I will commit the changes.

[Jenna]

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.

There is no guarantee, that each an every possible make command works this way.
In fact gnu-make returns 2, if an error occurs and 1 if it was called qith -q and a rebuild of any of the targets is needed.

Forcing LC_ALL or whatever makes sense on windows or Mac does not make sense, because the user can have a modified version of the regexes, that would break if we force english as language in any cases.

[kriegaex]

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.

You are right. I must have stumpled upon this option dialogue right after having installed C::B and forgotten about it, later wondered why the variable was gone and erroneously re-entered it in the wrong spot, global variables (as can be seen in one of my screenshots).

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. 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. But for me personally English is just fine, as long as I know that I need to manually set it. In order to minimise your support efforts and the number of ticket and forum activity on this topic though, I guess it would be a good idea to find a way to make the default settings work out of the box. Defaults which do not work are always a problem in software, especially because newbies start with defaults. Unless you find a way to make it work out of the box, you could at least show a warning dialogue before issuing the make if the language settings are different from what you expect. Calling make -v test-wise to parse default output can help you determine if the language is English or not. (Just thinking aloud, there is not much thought or analysis behind it.) This would work regardless of the platform (Linux, Windows, MacOS). A popup like "Attention: Your language settings seem to be non-English. This might cause problems in build output parsing (errors, warnings). You might want to set a global environment variable which sets the console language to English." might be helpful, maybe including a wiki link which explains more details or provides platform-specific hints about how to do that. I guess 90+% of German users will probably install their OS in German. The same applies to other localisations.

[oBFusCATed]

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? 

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).

But you're right that we should make Codeblocks work out of the box, when the user is using some non English locale.
But I doubt this will always work. What happens if the user has no en_US.utf8 or en_GB.utf8 locale installed?

@devs: have someone tried to force the locale inside the compiler plugin?

p.s. simple export LC_MESSAGES=... doesn't work for gcc on my CentOS 5.6, which is pretty strange.

[Jenna]

It might be possible to have an annoying dialog which is called if wxLocale::GetSystemLanguage returns a non-english language.
But I don't know how reliable this function works.

@devs: have someone tried to force the locale inside the compiler plugin?

p.s. simple export LC_MESSAGES=... doesn't work for gcc on my CentOS 5.6, which is pretty strange.

I use LC_ALL in my envvars (set default).

And I try not to use localized software where ever possible, because it's much easier to search the web for issues, if you use default (in most cases english) settings.

[kriegaex]

LC_ALL=C should always work (but do not take it for granted, I am not an expert there).

As for annoying dialogues, usually it works like this: They are shown, have a message and an additional checkbox, saying "don't annoy me again". So the user is free to choose is she likes to be reminded or not. Usually somehwre in the menu you can reset the warning dialogues so they are shown again.

[MortenMacFly]

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.

[thomas]

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.

As for localization, I don't think we should be doing anything. No matter what angle you look at it, localization is a lot of shit, both in general and in particular. It goes far beyond replacing "Warning" with "Warnung".
In the light of the trouble involved, I think it's acceptable to expect a developer to run the compiler without localization. It's what 100% of the German developers in the dev team do too, as far as I know

[MortenMacFly]

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?!

The only issue I see is that of course this only applies to compiler actually using localisation and where you actually can disable it. If I think about VC (for example) this is not the case. So the warning should say something like:
"Be aware that using a locale other than neutral / English might break the compiler output parsing of Code::Blocks build system. Either you switch your locale to English, or you need to adjust the RegEx parsing in the advanced compiler options, if needed. This might not apply to compilers other than GCC."

[kriegaex]

C::B's annoying dialog already works like that.

I know, this is why I quoted it. I thought the chance to get it this way would be good because the effort would probably be small. ;-)

No matter what angle you look at it, localization is a lot of shit, both in general and in particular.

I translate this to "localisation should be done right and is a lot of work". Then I agree. If you do think it is a lot of shit, I strongly disagree. Even though I am fluent in English and have no problem using C::B in English (if it works out of the box in a localised environment, that is), I think localisation is helpful and I enjoy using software in my mother tongue. So do a billion or so other people. Software is made for users, not for the developers who build it (only if the developers care to be the only users). And users run software in the context of a (possibly localised) OS. Not doing localisation because of scarce development resources and other priorities is okay, but not doing it because of an attitude like "it is a lot of shit" is just being lazy and snobby. So as I said, thomas, I guess you probably meant "hard to do" or "a lot of work".

[Jenna]

The actual packages on my server have the fixes for your issue.
See http://apt.jenslody.de/ for information how to use it.

[kriegaex]

Thanks Jens. A few questions in advance because I am not a package management expert:

• Can I somehow install the package in parallel to the Ubuntu 11.10 one? If so, how?
• If not: How stable is your trunk? Depending on your SCM policy it could be stable or not.
• If I temporarily upgrade my installation, can I downgrade again without trouble for config and project files? If so, how do I do that?
• 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.

[Jenna]

Thanks Jens. A few questions in advance because I am not a package management expert:

• Can I somehow install the package in parallel to the Ubuntu 11.10 one? If so, how?

No.

• If not: How stable is your trunk? Depending on your SCM policy it could be stable or not.

I use it for my daily work,

• If I temporarily upgrade my installation, can I downgrade again without trouble for config and project files? If so, how do I do that?

Yes, you have to remove my repo from the sources list and most likely uninstall C::B completeley and than reinstall the ubuntu version.

• Is the patch optionally available for the version on which the Ubuntu package is based?

No, I don't know on which version their package is based, but backporting it should not be too hard (it's svn r7895).

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.

[kriegaex]

I wrote it earlier in this thread: The "about" dialogue in Ubuntu 11.10 says: "svn 7671".

Thanks for your patience. I am gonna test it later this afternoon. :-)

[kriegaex]

Okay, I just quickly tested the version from your repository, Jens. It was a bit tedious to get it running because I have Ubuntu, so I had to also switch the wxwidgets repo, as described on your info page. After that, the plugin for global variables (where I defined my SUDO_ASKPASS) was gone because package "codeblocks-contrib" had been deactivated before and needed to be reinstalled. Even after reinstallation and even though I had not saved the project changes from the previous try and even though the variable was visible in the plugin's dialogue, it was not used. Only after I dummy-edited it and re-applied it, it was used. Very strange.

Anyway, I am filing this under one-time "upgrade / repo switch issues". As for the bugfix: It works. I hereby confirm that in my environment I can now use the combination of "task description" logging mode and custom make commands as expected. For instance, my "sudo -A $make ..." is executed as specified.

Thanks for your swift reaction and for your help, which is appreciated.