Needs ability to control inclusion of Arduino.h

[night-ghost]

New versions of IDE automatically adds #include "Arduino.h" to top of project. This breaks alternate serial libraries such as FastSerial or my SingleSerial which must be included BEFORE standard HardwareSerial.

So there should be checkbox somewhere in settings which can turn off this automatic inclusion.

[matthijskooijman]

How do these alternate serial libraries work? They define their own Serial object and then #define HardwareSerial_h or something like that to prevent the real HardwareSerial.h from acting when it is included by Arduino.h? Why not just let these serial libraries expose an alternative name, e.g. use FastSerial instead of Serial? If that annoying because it requires changing code, #define Serial FastSerial could help (in the FastSerial header file, or, probably better, in the sketch itself)? Or is there some other feature in those libraries that requires inclusion before the original?

[matthijskooijman]

Note if there are no references to Serial in the sketch, it will not be initialized and the ISR for it will not be included in the link, so there's not necessarily a conflict from including two different serial implementations.

[lmihalkovic]

Too much magic kills the magic... I think it makes sense to use different names for different object rather that to try to sneak behind. And the issue of making code compatible with both implementations could be addressed in a FastSerial example showing how to use a #define or a typedef to map a MySerial to Serial or FastSerial inside the sketch. This would have the merrit of educating base users to become more aware of the underpinning. But if this is too advanced for base .INO level then the core team could add a .INO ONLY instruction that the builder would rewrite as proper c++ during the rewrite phase. Something like "alias FastSerial as Serial". Then it looks simple, is completely under control of ArduinoLLC, and does the job.
Just a thought.

I think a lot of simple things could be done like that to improve capabilities while retaining both control and external simplicity. After all, INO = cpp + some (maybe it is time to consider adding some (I should probably not suggest too much in that direction as it will break my lexing of cpp source, but i think it is still worth keeping that direction in mind)

[matthijskooijman]

@lmihalkovic, yeah exactly, having such magic renaming happen in the sketch instead of a library makes it less surprising for users, at the cost of a little complexity in the sketches. As for adding a new 'alias' directive, I'd think that just using #define would be better, since further deviating from standard C++ is probably more harmful than helpful (and definitely more complex on the IDE implementation).

[lmihalkovic]

 further deviating from standard C++ is probably more harmful than helpful (and definitely more complex on the IDE implementation)

IMHO part of the brilliance of the idea of INO vs CPP is that it is a preproc on steroid that lets ArduinoLLC invent clever ways to deviate from the standard when they deem it useful to bring extra simplicity for the base users. The fact that it makes implementation more work is IMHO our problem to deal with.

[night-ghost]

Yes they define Serial object and then #define HardwareSerial_h
Why not use FastSerial? Because of another libraries that uses Serial and don't see my ##defines. And this libraries Intended to be "drop-in" replacement of HardwareSerilal.

There should be a free choice of library used, but now HardwareSerial nailed and one just have to patch and delete files when install the new version of Arduino

[lmihalkovic]

There should be a free choice of library used,

Amen to that one... I am working on that in my fork: users will select libraries from a list called references in the navigation outline. They can also inspect the source code for that library even if they cannot yet modify it (but they can modify libraries inside the sketch)

[matthijskooijman]

There should be a free choice of library used, but now HardwareSerial nailed and one just have to patch and delete files when install the new version of Arduino

That's a fair point - if backward compatibility were not an issue, it would probably be better if a sketch had to explicitely #include <HardwareSerial.h>. Not so easy to change now, though. Also, in this case I'm not convinced that you can't just replace HardwareSerial, though perhaps the approach you've chosen is not possible (anymore).

Why not use FastSerial? Because of another libraries that uses Serial and don't see my ##defines. And this libraries Intended to be "drop-in" replacement of HardwareSerilal.

But you would have to modify those libraries anyway to add #include <FastSerial.h> right? Without that, your HardwareSerial_h trick wouldn't work either, right? And if you really want the #include <FastSerial.h> to be the only needed change, you can just add the #define Serial HardwareSerial in FastSerial.h, right?

[night-ghost]

" there's not necessarily a conflict from including two different serial implementations." - checked not once, GCC says error "vector 18 defined twice" so only not to include

[matthijskooijman]

@night-ghost, could you provide a link to the library you used and a short sketch that illustrates the example, so we can reproduce? What Arduino version are you using?

Normally, the linker should only pick up the HardwareSerial object files (which include the ISR) from the core.a file only if a reference into that object file exists. This was specifically engineered to allow a sketch or library to use the ISR if HardwareSerial is not used. If this mechanism is not working, that's a bug we should fix.

[night-ghost]

any ArduPilot-related code (uses FastSerial as base), MinimOSD as example. In Arduino 1.6.1 all was OK but underground inclusion of Arduino.h which does Arduino 1.6.6 breaks it. My fork of MinimOSD (https://github.com/night-ghost/minimosd-extra) uses SingleSerial (which is simplified and optimized FastSerial) so it breaks too.

[matthijskooijman]

I'm sorry, but I won't be digging around in libraries or custom cores trying to figure out what I would need to install and compile and then hope what I picked actually triggers the problem. Please provide a more specific example (ideally just a single, small, sketch and a single library, or otherwise a bigger sketch and a list of libraries).

[night-ghost]

Problem is that simple sketch with single library works fine. But when I needs MAVlink I uses its library GCS_mavlink, ok? It requires some other libraries so I must ##include them too - and in result there is minimal possible set if libs.

But stop! I asks not about libraries etc - I asks about simple checkbox somewhere in configuration to TURN OFF underground activities and restore expected behavior.

Now I simple delete files HardwareSerial?.* by small .sh and all OK so feature I asks not for current needs but was trying to make a better world. It seems not work

[matthijskooijman]

Right, then I'll leave this request to the consideration of the Arduino team, instead of trying to figure out a way to make your code work with the current version of the Arduino IDE.

[night-ghost]

My code and large amount of another code (very complex code!) works fine before one feature change in Arduino new version. In result ArduPilot team drops support of Arduino IDE and turns to Makefiles.
Such incompatible feature is flaw of Arduino team, is'nt it?