Go Down

Topic: Compiler continue to use commented out #include headers (Read 7388 times) previous topic - next topic

Vaclav

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!


MarkT

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....
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]

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. 

AWOL

Quote
After unzipping the Menu library it

The Menu library?

Which one would that be?

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

Grumpy_Mike

#4
Sep 23, 2014, 09:13 am Last Edit: Sep 23, 2014, 10:59 am by Grumpy_Mike Reason: 1
Quote
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?


bobcousins


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.
Please ask questions in the forum so everyone can benefit. PM me for paid work.

MarkT



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.



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
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]

bobcousins

#7
Sep 23, 2014, 07:40 pm Last Edit: Sep 23, 2014, 11:39 pm by Coding Badly Reason: 1

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 https://groups.google.com/a/arduino.cc/forum/?fromgroups#!topic/developers/Y7waXnTVjkw
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
Please ask questions in the forum so everyone can benefit. PM me for paid work.

bperrybap



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

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

bperrybap


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

AWOL

#11
Oct 08, 2014, 07:40 am Last Edit: Oct 08, 2014, 11:52 am by AWOL Reason: 1

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

robtillaart


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


Check - https://www.kickstarter.com/projects/24519005/controllino-plc-arduino-compatible -

looks quite robust to me :)
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

bobcousins



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


Check - https://www.kickstarter.com/projects/24519005/controllino-plc-arduino-compatible -

looks quite robust to me :)



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.

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

When the going gets tough, order donuts? :D
Please ask questions in the forum so everyone can benefit. PM me for paid work.

AWOL


Go Up