User forums > Using Code::Blocks
Custom make commands are never executed
Jenna:
--- Quote from: kriegaex on March 11, 2012, 09:00:19 pm ---
--- Quote ---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.
--- End quote ---
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).
--- End quote ---
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>
--- End code ---
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:
--- Quote from: kriegaex on March 11, 2012, 09:00:19 pm ---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.
--- End quote ---
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:
--- Quote from: jens on March 12, 2012, 06:37:02 am ---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.
--- End quote ---
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:
--- Quote from: kriegaex on March 12, 2012, 10:36:29 am ---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.
--- End quote ---
Unit tests? What is that? :P ::)
--- Quote from: kriegaex on March 12, 2012, 10:36:29 am ---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.
--- End quote ---
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.
--- Quote from: oBFusCATed on March 12, 2012, 11:58:10 am ---@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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version