Implement "activate" and "deactivate" script for easier and reversible installation

[iFreilicht]

From #4:

Additionally, it seems to me like there is little reason to actually execute step 3 of the installation instructions. Step 4 seems to be enough. I could see the argument of wanting to give more accurate error messages to people who accidentally import libraries using the USB core. Either way, it would be enough to just append .removed to the filenames of these files and to enclose the lines in step 4 with #if 0 and #endif or / and /. This way it would also be easier to activate and deactivate LUFA in a regular Arduino installation. To implement this, I'd write a simple script that does exactly what I described above, and another one to reverse these changes.

To make these two scripts cross-platform, I'd implement them in Python. The deactivate script would import the activate one for all paths, so it can be guaranteed that it always perfectly reverses what the activate script did.

Maybe "activate" and "deactivate" aren't prefect names for these yet, I'm open to suggestions on that front.

Another idea would be to ship the LUFA.h file with an #error directive that gets commented out by the activate script to give a descriptive error message when a user tries to include the LUFA library without activating first. In the same vein, instead of renaming the USB-related files, we could just insert an #error directive at the top of each of them, so when a user tries to compile another project that uses the Arduino USB stack, they get a descriptive error message as well.

Thoughts?

[iFreilicht]

I tried out the simple #error thing, but apparently the Arduino IDE compiles all of the .cpp and .h files in the core, even if they're not required, so that doesn't work. Maybe enclosing it in #ifdefs with a matching #define in LUFA.h would work. I'll try that tomorrow.

[Palatis]

enable_arduino_core_usb.py disable_arduino_core_usb.py

i think wrapping core arduino files with #if !defined(NO_CORE_USB) would be a good idea, can also push that to arduino repo.

[iFreilicht]

Those are pretty descriptive, I like them.

Good point, having a dedicated macro to do this would actually be a way better solution. But, doesn't the Arduino IDE always insert #include <Arduino.h> at the very top of the main .ino file? Because then this wouldn't work.

[Palatis]

one can create custom board config to specify command line arguments for gcc.

[iFreilicht]

True, but then you'd have to maintain custom board configurations for every single board. On the other hand, that would avoid any confusion which boards can actually use LUFA and which can't.

Right now it seems like too much work for too little benefit. I'm sure the few users that do care about using LUFA on Arduinos are able to run a script whenever they switch between LUFA and non-LUFA projects. If there are any complaints that switching is too tedious, then we can talk about custom board configurations again.

I'll modify my scripts to just wrap the whole file in a comment instead of putting an #error directive at the top.

[Palatis]

I actually think this is the correct way to go, let me explain...

1. there are not that many ATmega32u4 boards out there (maybe just 4 or 5, AFAIK...), the list won't get too long.
2. we don't have to add every single board to the list in the first place. we can go as someone has to work with a particular board. this way we know that LUFA is working on that board, because someone got it working and sends a PR.

for example,

• you have an Arduino Micro, so you write the board config for Arduino Micro because you tested it and no doubt that board will work.
• and I have an Arduino Leonardo, so I write the board config for Arduino Leonardo because I tested it and no doubt that board will work.

woot! nothing breaks.

[Palatis]

but yeah I think you're right, most people who dig into LUFA should probably be having no problem running some shell/python scripts. let's just do whatever we need to get it working right now, and see if someone else actually file an enhancement issue. :-P

I'm such a lazy programmer...

[iFreilicht]

True, there aren't many boards that would actually want to run this.

Let's just remember it for later on :)

I'm such an efficient programmer...

FTFY