autoselect avrgcc

it would be great to autoselect avrgcc compiler when needed for .c .cpp files.

maybe if there is an include line :
#include

what about detecting Device too. For exemple by adding in source file :
#define device attiny13

i can try to implement that

There is already something similar implemented:

You can add a comment at the very first line of the file and define: compiler, device, family, board (for Arduino).
For example:

Code:

// Compiler: Avrgcc  device: attiny13

Have a look at:
src/gui/editorwidget/basedebugger.cpp, BaseDebugger::getInfoInFile( QString line )
src/gui/editorwidget/codeeditor.cpp, CodeEditor::setFile( const QString filePath ) around line 188.

ok, i had seen src/gui/editorwidget/codeeditor.cpp but skipped some things !

works great ...
but it must be added before saving the file for the first time :
when i add the line in a file which is already saved, compiler is not update whereas device does :
No Compiler Defined
Found Device definition in file: atmega640

perhaps it could be checked before
int error = m_compiler->compile( debug );
in CodeEditor::compile method ?

or when the file is saved before compile ?

when i add the line in a file which is already saved, compiler is not update whereas device does :

Yes, device, family and board only add information to the current compiler.
But setting the compiler creates a Compiler object.
That's why the detection are in different places.

In my previous post I was watching to 1.0.0 source code, but in trunk, compiler is detected when the file is opened:
src/gui/editorwidget/codeeditor.cpp, CodeEditor::setFile( const QString filePath ) lines 105 to 113.

perhaps it could be checked before
int error = m_compiler->compile( debug );
in CodeEditor::compile method ?

or when the file is saved before compile ?

I think any of those could work.
In most cases when you compile the file has changed and needs to be saved.

But it should check if the compiler has actually changed, then if it changed, delete the old compiler(if it exist) and create a new one.

Probably move that code (lines 105 to 113) to a function "findCompiler()" or something like that and call it from CodeEditor::setFile and CodeEditor::compile if( document()->isModified() )

Bas has proposed merging lp:~bastien-jacquot/simulide/simulide into lp:simulide.

Commit message:
update compiler from source file before compile

Merged at Rev 1516.

thx.
i added a bug on launchpad (with a possible patch) for another problem.

i added a bug on launchpad (with a possible patch) for another problem.

I continue the discussion here...

compilations errors are not detected with avrgcc.
problem is that gcc output are translate...
...
change LANG environment variable when compiling ?

Problems I see:
- Probably not working in Windows.
- Message translation is lost.

Possible alternative (only for avrgcc):
Error messages start with: file.ext:lineNum:CHNum:

- Override Compiler::getError() in AvrGccDebugger
There check if the string starts by m_fileName+m_fileExt+":" instead of contains "error".

Or maybe:
- Create a virtual funtion: bool hasError( QString txt )
This function is called in Compiler::getError(): if( !hasError(txt) ) continue;

Then Compiler::hasError() will be: line.contains( QRegExp("\\berror\\b")
And AvrGccDebugger::hasError() will be: starts by m_fileName+m_fileExt+":"

Just an idea...
Maybe there are other ways.

Message translation lost is not a big deal in my opinion since they are most likely not entirely translated :

/file.cpp:14:10: attention: «n» is used uninitialized in this function

/file.cpp:14:9: erreur: «n1» n'a pas été déclaré dans cette portée

Error and warning messages starts with same patterns.


I'm almost done with compiling on windows, will try with LANG environnement variable.

arduino compiler messages are not translated
test.ino:3:2: error: 'n' was not declared in this

Error and warning messages starts with same patterns.

Yes that rules out this approach.

We forgot about the fundamentals: process exit code...

This is not applicable to all compilers because many don't use it or use it in any imaginable way.
But for avrgcc all that is needed is checking for exit code != 0

ok, but where is checked (and how) on which line the error is in order to show it with red dot ?

my windows tests :
-> avr-gcc is not localized so it worked as is, errors/warnings are well detected
-> with modifying LANG environnemennt variable this works too

for the translation lost problem, it's only on linux (maybe mac ?) and for other compilers ( at least arduino) it's alreary not translated. And there is the problem of only partially translated messages.

ok, but where is checked (and how) on which line the error is in order to show it with red dot ?

To get the exit code:
int ec = process.exitCode();

To get the error line:
The first line containing line name shows the first error.

Removing the translation is not a big deal for me as well, but could be for some people in some cases.
In any case if we can solve the issue while keeping the translation is better.

-----------------------------------------------

Getting this to work in all cases with only one rule is impossible.
And the current approach of getting lines with string "error" fails in many cases.
For example some compilers use "no errors found" and "3 errors found"


I see 2 problems:

1- SimulIDE messages about compilation successful or failed is not reliable:
I think the best option is just to remove these messages and only show the compiler output.

2- Detecting the error line:
This one is tricky...

- First we need to know if there is an error:
I did a bunch of tests with different compilers and found that exit code is more reliable than string "error", even a compiler that didn't use exit codes some time ago is using it in last version.

- If there is an error, the first line containing the file name usually refers to the first error location (including avrgcc).
The exact format varies from compiler to compiler, but in general the first number after the file name is the line number of the error.

Currently SimulIDE can only get the error line number if the format is the same than avrgcc: fileName:lineNumber:charNumber
This can be improbed:
Detect the first number after file name regardless of the format, for example:
fileName(lineNumber)
fileName\n(lineNumber)
fileName,lineNumber

In some cases nothing will work, but at least we don't show the wrong message about compilation successful or failed.

I implemented error by exit code, improved first error line detection and removed success/fail messages at trunk Rev 1520.
It works better with most compilers.

There is still an issue I would like to address that might need the "error" string detection:
Finding line numbers for all errors and showing red dots in line number area and marks in the scroll bar, similar to breakpoints or "Find All" in Find/Replace dialog.

Great.

arcachofo wrote:
Finding line numbers for all errors and showing red dots in line number

I was thinking about that too.
What about compiling twice to simplify translations problems :
One's for printing translated message, one's in english for parsing.

Showing warnings too with orange dots ?

One's for printing translated message, one's in english for parsing.

That's an option, but it takes twice the time, for large projects in slow computers it could be an issue.
Maybe some compiler might do nothing the second time if the source has not changed and the output files are still there.
And the code would be a bit more complex.

Showing warnings too with orange dots ?

Yes, that would be great.

In any case this is not fully solved yet, your proposal just opened a "full review" of this part of the compiling system.

As I mentioned before I see 2 problems to address:
1- Detecting that there is an error.
For this I find exit code more reliable (and faster), but could still fail if a compiler does not use exit codes or do funny things with it(*).
Now at least there are not misleading messages "Success" when indeed the compilation failed.
The worst that can happen is that error line is hot detected, but the error messages from the compiler are still in the bottom panel.

One option that comes to my mind is always doing the build in a hidden empty folder.
Then if we find the hex file there we know that the process was successful and copy all the files to the actual build folder overwriting older ones.
If we don't find the hex file then we know that something went wrong.
But this makes things more complicated, slower and could be problematic in some cases.
Maybe it could be an option only for compilers that are known to not work properly in our general case...


2- Extracting information from the process output.
This process iterates along all the text to find strings, so it's potentially slow.
Currently this only happens if an error is detected (via exit code) and only until the first error if found.
But if we want to find all errors and warnings this should also change(**).

So if we want to address (*) and (**) we are forced to go through the "Extracting information" process in all cases.
There are some setting we could add. like: "Show all errors" and "Show warnings", so the user can choose.

If we need to find all the error and warning messages, disabling the translation is probably the best option.
But there are many possible approaches depending on what we want.

what do you think about something like that :

https://bazaar.launchpad.net/~bastien-jacquot/simulide/simulide2/revision/1524

sorry I'm not comfortable with bazaar !
of course with 2 QList for errors and warnings.
https://bazaar.launchpad.net/~bastien-jacquot/simulide/simulide2/revision/1525
https://bazaar.launchpad.net/~bastien-jacquot/simulide/simulide2/revision/1526

and use exitCode from m_compProcess for Compiler::getErrors return value ?

bjacquot wrote:what do you think about something like that :

https://bazaar.launchpad.net/~bastien-jacquot/simulide/simulide2/revision/1524

sorry I'm not comfortable with bazaar !
of course with 2 QList for errors and warnings.
https://bazaar.launchpad.net/~bastien-jacquot/simulide/simulide2/revision/1525
https://bazaar.launchpad.net/~bastien-jacquot/simulide/simulide2/revision/1526

and use exitCode from m_compProcess for Compiler::getErrors return value ?

Yes that looks great.
I will add your changes, do some tests with as many compilers as I can and let you know if I find some issue.

Added your changes at trunk Rev 1524.

I did some modifications for convenience: moved lists to CodeEditor and some other minor changes.
Improbed a bit the appearance and added marks in the scroll bar.
Also solved the problem when adding/removing lines: errors, warnings & brkpoints should move with the line.