Compiler continue to use commented out #include headers

After unzipping the Menu library it was recognized by IDE , added to editor file using Import Library and then it would not compile.
This is pretty much known behavior and can be fixed by moving the files into Arduino libraries folder from folder where it was downloaded into. No problema.

However, after commenting out the #include code the compiler continue to use these commented out headers!
Spitting out tons of errors caused by wrong enviroment path.

Unfortunately SAVING the file with uncommented #include files , now commented out, made the *.ino file useless!

If you give a concrete, repeatable set of steps for recreating the problem
it will help people understand what the problem is. Its not clear to me what
you did to what, where....

Are you in a position to DO something about this or not? I am not going to write pages of documentation just to clarify the problem to someone who just wants to know more unnecessary details. Sorry, read the OP again.

After unzipping the Menu library it

The Menu library?

Which one would that be?

Clear, repeatable steps, please, like the man said.

However, after commenting out the #include code the compiler continue to use these commented out headers!

So you think the compiler is ignoring the commenting out bit do you?

What happens if you remove the include line completely?

Vaclav:
However, after commenting out the #include code the compiler continue to use these commented out headers!
Spitting out tons of errors caused by wrong enviroment path.

From the limited information provided, I think this may be a known problem, if so it has been mentioned on the dev list. The IDE does a simple regex to scan the ino file for "library includes", and it ignores comments and ifdefs, unfortunately it can pick up libraries that are not actually in use.

I think the only workaround is to delete any include lines that are not in use. To solve this properly might need a complete C parser in the IDE, which is impractical.

bobcousins:

Vaclav:
However, after commenting out the #include code the compiler continue to use these commented out headers!
Spitting out tons of errors caused by wrong enviroment path.

From the limited information provided, I think this may be a known problem, if so it has been mentioned on the dev list. The IDE does a simple regex to scan the ino file for "library includes", and it ignores comments and ifdefs, unfortunately it can pick up libraries that are not actually in use.

I think the only workaround is to delete any include lines that are not in use. To solve this properly might need a complete C parser in the IDE, which is impractical.

If its a known problem is there an open issue on GitHub? A quick search there wasn't
convincing.

Vaclav:
Are you in a position to DO something about this or not? I am not going to write pages of documentation just to clarify the problem to someone who just wants to know more unnecessary details. Sorry, read the OP again.

Well if there was a half-decent amount of detail about recreating the problem I could
raise an issue on Github for you I suppose... But I couldn't even understand what you
were talking about.

The procedure for reporting bugs is documented here:
http://arduino.cc/en/Main/ContactUs

A simple description of how to recreate a problem is the minimum starting
point for a bug report. Read this for more insight:
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

MarkT:
If its a known problem is there an open issue on GitHub? A quick search there wasn't
convincing.

The most recent discussions where this came up is in this thread Redirecting to Google Groups
I'm not aware of any open issues about it either.

It would help to see some code samples, it's easy to assume it is one problem when it could be something quite different. Use cases also help maintainers understand the issue and verify fixes.

Moderator edit: link corrected

bobcousins:

Vaclav:
However, after commenting out the #include code the compiler continue to use these commented out headers!
Spitting out tons of errors caused by wrong enviroment path.

From the limited information provided, I think this may be a known problem, if so it has been mentioned on the dev list. The IDE does a simple regex to scan the ino file for "library includes", and it ignores comments and ifdefs, unfortunately it can pick up libraries that are not actually in use.

I think the only workaround is to delete any include lines that are not in use. To solve this properly might need a complete C parser in the IDE, which is impractical.

The compiler is not the issue. The IDE is the problem
The IDE has attempted to do way too much inside it rather than try use existing tools better or
try to coax the users to a little bit more.
It isn't just commenting out a header that will create issues for the IDE, a more common and potentially more complex
case is when conditional compilation is done.
The same problem also exists for function prototypes.
The IDE could be smarter by doing the scan for includes for libraries and functions (to generate prototypes) in multiple passes.
The first pass would scan the sketch and would set up include paths for the c-pre processor (not the compiler)
Then run the c-prepressor with those include paths to do the only pre-processing on the sketch.
The second pass would scan the pre-processed file for the actual includes used and functions used.
Then the IDE could use that list of includes (which are the includes really used) and functions
and proceed just like does now.

There are many other parsing issues in the IDE that could also be solved if the IDE would simply
use a double scan approach that involves the C pre-processor rather than trying to do all
the parsing itself.

--- bill

bperrybap:

bobcousins:

Vaclav:
However, after commenting out the #include code the compiler continue to use these commented out headers!
Spitting out tons of errors caused by wrong enviroment path.

From the limited information provided, I think this may be a known problem, if so it has been mentioned on the dev list. The IDE does a simple regex to scan the ino file for “library includes”, and it ignores comments and ifdefs, unfortunately it can pick up libraries that are not actually in use.

I think the only workaround is to delete any include lines that are not in use. To solve this properly might need a complete C parser in the IDE, which is impractical.

The compiler is not the issue. The IDE is the problem
The IDE has attempted to do way too much inside it rather than try use existing tools better or
try to coax the users to a little bit more.
It isn’t just commenting out a header that will create issues for the IDE, a more common and potentially more complex
case is when conditional compilation is done.
The same problem also exists for function prototypes.
The IDE could be smarter by doing the scan for includes for libraries and functions (to generate prototypes) in multiple passes.
The first pass would scan the sketch and would set up include paths for the c-pre processor (not the compiler)
Then run the c-prepressor with those include paths to do the only pre-processing on the sketch.
The second pass would scan the pre-processed file for the actual includes used and functions used.
Then the IDE could use that list of includes (which are the includes really used) and functions
and proceed just like does now.

There are many other parsing issues in the IDE that could also be solved if the IDE would simply
use a double scan approach that involves the C pre-processor rather than trying to do all
the parsing itself.

— bill

Thanks for the explanation.
As an IDE issues it seems strange that basic C syntax is ignored. it seems to be very poor practice to bypass time honored ( and working) processes (function prototyping) with something which generates misleading errors and in an essence does not work. Is the time saved by not running multiple passes really worth it? I suppose if majority of users run "blinking LED’s " it does not matter. But on the other hand it makes Arduino poor candidate for "industrial strength " application. Too bad.
Cheers Vaclav

Vaclav:
Thanks for the explanation.
As an IDE issues it seems strange that basic C syntax is ignored. it seems to be very poor practice to bypass time honored ( and working) processes (function prototyping) with something which generates misleading errors and in an essence does not work. Is the time saved by not running multiple passes really worth it? I suppose if majority of users run "blinking LED's " it does not matter. But on the other hand it makes Arduino poor candidate for "industrial strength " application. Too bad.
Cheers Vaclav

Not quite sure what you mean.
"based C syntax" ? I'm assuming you mean conditionals (ifdefs etc..) ?
If so, that isn't C syntax, but rather the C pre-processor.

The problem is the IDE.
The IDE, in my opinion is trying to do too much in a single monolithic application.
The biggest issue is that there was a desire to not require users to use proper C/C++ syntax
in an attempt to try to make it simpler/easier for them.
It is a great goal to try to make it simpler for newbies by not requiring them to write proper C/C++ code.
The IDE is attempting to convert the user's sloppy & incomplete C/C++ code into valid C/C++
This includes generating the needed function prototypes.
This is a VERY difficult thing to do, especially if trying to do all the parsing vs leveraging
using the C pre-processor.
I've not seen other IDE's that do this.

In my opinion, the parsing methodology is just one of many issues in the current
Arduino IDE build methodology.
How "libraries" and include paths are handled is another gigantic can of worms.

--- bill

Vaclav:
I suppose if majority of users run "blinking LED's " it does not matter. But on the other hand it makes Arduino poor candidate for "industrial strength " application. Too bad.
Cheers Vaclav

From the Arduino home page

Arduino is an open-source electronics platform based on easy-to-use hardware and software. It's intended for anyone making interactive projects.

I'd say it does pretty well in its stated aim.
Industrial strength users will have industrial strength tool chains, industrial strength hardware, industrial strength input and output protection, and industrial strength price tags.

Vaclav:
... But on the other hand it makes Arduino poor candidate for "industrial strength " application. Too bad.

Check - CONTROLLINO PLC (ARDUINO compatible) by SG-TRONIC INC — Kickstarter -

looks quite robust to me :slight_smile:

robtillaart:

Vaclav:
... But on the other hand it makes Arduino poor candidate for "industrial strength " application. Too bad.

Check - CONTROLLINO PLC (ARDUINO compatible) by SG-TRONIC INC — Kickstarter -

looks quite robust to me :slight_smile:

Hmm, their first campaign failed, I don't think this one will succeed either. I can't see where the Open Source bit is either. Kickstarter seems entirely the wrong channel for this type of product, I can't imagine many industrial users sourcing equipment from a startup with no track record, let alone Kickstarter campaign.

If in any event a delay is eminent ... we will immediately inform our bakers.

When the going gets tough, order donuts? :smiley:

I’ve never heard of an “eminent” delay.

Vaclav:
After unzipping the Menu library it was recognized by IDE , added to editor file using Import Library and then it would not compile.

...

Unfortunately SAVING the file with uncommented #include files , now commented out, made the *.ino file useless!

This is, sadly, a mumbo-jumbo report.

After unzipping the Menu library ...

What library? Link? Where did you unzip it to?

... then it would not compile.

With what error messages? What did you compile, exactly?

This is pretty much known behavior ...

Oh? Link to this known behaviour?

and can be fixed by moving the files into Arduino libraries

What files? Where were they before?

after commenting out the #include code the compiler continue to use these commented out headers!

Proof?

Spitting out tons of errors caused by wrong enviroment path.

What errors? Copy and paste them here.

What environment path are you talking about?

it seems strange that basic C syntax is ignored.

What do you mean by that? What syntax? Prove it is ignored. Show the syntax. Show the "ignoring".

made the *.ino file useless

How can a file become useless?

Look, Vaclav, after over 400 posts you should know by now to not ramble on, but to paste your code and your error messages.

I was mulling this over and I think bill has a workable suggestion which may have been overlooked:

The IDE could be smarter by doing the scan for includes for libraries and functions (to generate prototypes) in multiple passes.
The first pass would scan the sketch and would set up include paths for the c-pre processor (not the compiler)
Then run the c-prepressor with those include paths to do the only pre-processing on the sketch.
The second pass would scan the pre-processed file for the actual includes used and functions used.
Then the IDE could use that list of includes (which are the includes really used) and functions
and proceed just like does now.

To expand on what Bill said, the output of the preprocessor can be gotten using the "-E" flag. Although most of the source gets stripped, the "#line" directive is inserted into the output and specifies the source file, so that could be used to deduce what header files need including.

I'm not sure if that also helps with function prototypes, but I think it could help the include file problem. My java skills are minimal, but I will try to have a look at implementing this idea. I think it could be added as build step in Compile.java called when the libraries are being scanned for, instead of the regex currently done in PdeProcessor.java.

It's worth noting there are some major changes coming to the IDE, which will likely affect any implementation, but perhaps I can create a proof of principle.