User forums > Using Code::Blocks

Custom make commands are never executed

<< < (3/7) > >>

Jenna:
Good to hear that calling sudo works, but what I wanted to say, is that it is not guaranteed to work in any cases.

The other thing (not using the correct make-command if not full commandline logging is set) is definitely a bug and will be fixed as soon as possible.

When a fix will make it into ubuntu's repo is their (the ubuntu maintainer's) decision.

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.
A warning can be treated as error in some cases, because we use regexes to parse the output.

If you can copy the warning-message treated as error, it might be able to fix this.

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


--- Quote from: kriegaex on March 11, 2012, 01:30:19 pm ---[...]
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).

--- End quote ---
If you post such statements, you have to live with answers like the ones from MortenMacFly.

It's not very professional and to say C::B is absolutely useless is (sorry to say it that way) bullshit.
C::B has it's own very powerful build-system.
Using custom makefiles is not the normal usecase and it uses nearly nothing of the possibilities of C::B .

Nevertheless it should work without such bugs, but as you should know, there is not much software without bugs, so we are glad if a user finds and reports iussues.

And as the forum-rules clearly state:


--- Quote from: http://forums.codeblocks.org/index.php/topic,9996.0.html ---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.
--- End quote ---

No need to do it in this case, I will fix it anyway.
But when you have registered here, you accpeted to follow these rules, so please calm down and be patient.

Jenna:
Our posts have crossed.
Please use LC_ALL=en_US.UTF-8 (or something similar) in envvar-plugin.
German messages can not be paresed correctly.

That does not guarantee your message to be parsed correctly, if it is not a message from compiler/linker, but from the make-command.

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.

kriegaex:

--- Quote ---Please don't use local attachments. Storage for the forum is limited and attachments get removed at random!
--- End quote ---

I am sorry, I was not aware of that fact. Maybe you better deactivate uploads if you prefer your users not to upload anything. (I mean it literally, ironic as it may sound - no misunderstandings again just because I use explicit instead of euphemistic language, please.) I have no intention of spamming your forum. As you can see I did not post full-sized screenshots but cut out the relevant parts and decreased the colour depth to 8 bit. The files are numerous, but really small.


--- Quote ---It seems that I can reproduce your bug.
--- End quote ---

Cool, thank you. I will wait for the fix and then be happy to test it for you with my setup. :-)


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

--- End quote ---

No change in behaviour: The command is only called for full log.


--- Quote ---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
--- End quote ---

I guess that is a matter of perspective. 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. Please do not be angry at me if I say that, but if your default mode - which I think is really nice and useful except for the fact that it does not work at the moment (but this can easily be fixed, no problem) - does not work and you think it calls for trouble, why does that mode (a) exist at all and why is it (b) the default? No, please do not remove something useful, just do not be annoyed if your users find bugs and try to help you spot and fix them. This is part of the normal software lifecycle. I was just wondering why I was the first user finding that bug because it is so obvious. I guess that 99% of your users do not use external makefiles, but the internal build system, which makes sense for self-developed software. But as I said, I just want to patch and debug a piece of standard software with a set of existing, complex makefiles which I have no intention of changing. I was just adding a new MC featue (ash/dash subshell support + two bugfixes for existing subshells) and thought it would be a nice test for C::B's debugging front-end to test MC in C::B. Actually, I have not gotten that far just yet because I am discussing this issue here with you, but I think it is well worth the time to improve a product which obviously many other users are satisfied with.

When I was calling C::B useless, I meant it was useless for my specific use case, not all in all and for many other use cases. My remark had a context. So no, I will not accept answers like the one by MortenMacFly. There is no reason to feel insulted just because a user puts his finger into a wound, i.e. he reports bugs.

An IDE has three main use cases: edit code, build, debug. The second one was not working for me, so maybe you understand that in this context the program was useless for me. But now I know a workaround and am confident that the bug(s) will soon be fixed, so I will hang on and continue using C::B. Quality of software is one criterion for me to use software, quality of customer service another one. We had a bad start, but I guess now we are getting closer to finding a solution for the technical problems I detected in your product. This is fine with me.


--- Quote ---Good to hear that calling sudo works, but what I wanted to say, is that it is not guaranteed to work in any cases.
--- End quote ---

Why should it not? It is a subprocess like any other, too. The GUI dialog is the only way to enter the password because your console is not a real tty. This is exactly what SUDO_ASKPASS was invented for and it works with each editor or IDE I know. As I said, it is independent from or orthogonal to C::B.


--- Quote ---Alternatively you can use my repo (see my sig), if the bug is fixed and I uploaded a new version.
--- End quote ---

Thanks for your kind invitation, I am going to accept it. If you help me by fixing a bug, I will help you with testing and feedback. That's the deal. As we say in Germany: One hand washes the other one.


--- Quote ---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).
--- End quote ---

Yes, that must be it. I did not know that English was the only language supported by C::B, but on second thought, the menu is in English, so I could have concluded from that. I will just use LANG=C (I am on ISO-8859-15 here, not UTF-8, because I often develop for an embedded system with a cross-compiler, and the target system only supports latin1 character set). A quick test shows that the warning is interpreted correctly then.

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.
As for your suggestion to post bug reports at BerliOS, you can be sure I will do that next time. You are 100% right that if there is a ticket system, it should be used. When I was first posting here I was just not sure if as a newbie I should ring the alarm right away or first try to get some feedback in a user forum. I decided to do the latter and am sorry if this was the wrong place. I usually (not always) try first to ask experienced co-users before I consume precious developer time. But when I am sure that what I consider a bug really is one, I create tickets. If you like to have one for reference, I can do that anyway.


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

oBFusCATed:

--- Quote from: kriegaex on March 11, 2012, 09:00:19 pm ---...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...

--- End quote ---
It stimulates people to use the full log. :)
In fact using anything other than the full log in custom make file project is asking for trouble. :)
As I said, I'd prefer there were no other options.

Navigation

[0] Message Index

[#] Next page

[*] Previous page