Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Local include of this library into other projects #1012

Closed
Def3nder opened this issue Jan 9, 2020 · 7 comments · Fixed by #1013
Closed

Local include of this library into other projects #1012

Def3nder opened this issue Jan 9, 2020 · 7 comments · Fixed by #1013

Comments

@Def3nder
Copy link

Def3nder commented Jan 9, 2020

Hi David,

I love the IRremoteESP8266 library and the ESP32 support since 2.6.2 😄

However the number of different mostly air conditioner protocols occupies a lot of program space (like 28k). Changing the #defines in the IRremoteESP8266.h header file from "true" to "false" does resolve this problem.

Now my question: is it allowed to use an exact copy of this library e.g. v2.7.2 and add this to another project (not as include but directly in the src directory) and then make only these #define-changes ?

...or is there any way of getting the compiler to not use any SEND-code and no code for air conditioners ?

@crankyoldgit crankyoldgit self-assigned this Jan 9, 2020
@crankyoldgit
Copy link
Owner

Now my question: is it allowed to use an exact copy of this library e.g. v2.7.2 and add this to another project (not as include but directly in the src directory) and then make only these #define-changes ?

As long as you are complying with https://github.com/crankyoldgit/IRremoteESP8266/blob/master/LICENSE.txt then you are free to do so as you please.

IANAL but I think the relevant clauses are:

  For example, if you distribute copies of the library, whether gratis
or for a fee, you must give the recipients all the rights that we gave
you.  You must make sure that they, too, receive or can get the source
code.  If you link other code with the library, you must provide
complete object files to the recipients, so that they can relink them
with the library after making changes to the library and recompiling
it.  And you must show them these terms so they know their rights.

 We protect your rights with a two-step method: (1) we copyright the
library, and (2) we offer you this license, which gives you legal
permission to copy, distribute and/or modify the library.

or TL;DR: As long as you make this library's source & license freely (as in beer & speech) available, & don't claim it as your own (except for your modifications), then you can do with it as you please.

e.g. Tasmota & ESPEasy use/include/incorporate this library

...or is there any way of getting the compiler to not use any SEND-code and no code for air conditioners ?

Not easily. The #defines are the way to do it. I could change them to see if they are already defined before it defines them so you could pass a compiler-time flag. e.g. -DDECODE_KELVINATOR false etc. i.e. I could do it, but it would make code more unreadable than necessary IMHO.
e.g.
Existing:

...
#define SEND_NEC true
#define DECODE_NEC true
...

would become:

...
#ifndef SEND_NEC
#define SEND_NEC true
#endif  // SEND_NEC
#ifndef DECODE_NEC
#define DECODE_NEC true
#endif  // DECODE_NEC
...

Not impossible, but it's hard enough getting people to edit that file as is, let alone with the extra lines around them.

FYI, the compiler will only include the code you actually need/gets referenced. i.e. If you don't use an sendBlah calls, then it won't include/link them. Even if SEND_BLAH is set to true.

Decoding however is different. The main irrecv.decode() method will go through/link in EVERY protocol specific decode routine UNLESS you've disabled it via #define DECODE_BLAH false

There is no run-time way to say "only decode these few protocols" and ONLY include the compiled decode code for those protocols. Compile-time is the only way to exclude/reduce the included code.

I hope that answers your questions.

@crankyoldgit
Copy link
Owner

Oh, and the decode() routine won't pull in all the hip A/C controlling code to bloat your binary either. Unless of course you use it in some way.

@Def3nder
Copy link
Author

Def3nder commented Jan 9, 2020

Hi @crankyoldgit thanx a lot - yes, that helps !

Would it be another possibility to not locally include the WHOLE library but only the IRremoteESP8266.h file and change only that ? (and tell platformio to use the specific version where the header was copied from (e.g. @2.7.2) ?

...just tested this and: NO, it does not work. PlatformIO does compile libraries separately (first) and then the rest of the project, so it needs to be included completely.

@Def3nder Def3nder closed this as completed Jan 9, 2020
@crankyoldgit crankyoldgit reopened this Jan 10, 2020
crankyoldgit added a commit that referenced this issue Jan 10, 2020
Allow users of the library to externally control which protocols are 
used/enabled/compiled without having to modify the `IRremoteESP8266.h` 
file.
i.e. `SEND_BLAH` & `DECODE_BLAH` can be controled with preprocessor 
compiler flags (see 
https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html)

Fixes #1012
@crankyoldgit
Copy link
Owner

Hey @Def3nder , I've created a branch that should allow you to use the library without modification and control which protocols are compiled etc via -D flags to the compiler.

This should solve your issue and address any concerns w.r.t. use under different licenses.
i.e. You shouldn't need to duplicate the library within your own source tree.

Can you please test it out and let me know how it goes?

@Def3nder
Copy link
Author

Hi David,

thank you so much !
It does actualy work 😄

I changed the lib_deps_external from [email protected] to https://github.com/crankyoldgit/IRremoteESP8266.git#compile_flags and added the following build_flags:
-D_IR_ENABLE_DEFAULT_=false
-D DECODE_HASH=true
-D DECODE_NEC=true
-D DECODE_SONY=true
-D DECODE_PANASONIC=true
-D DECODE_JVC=true
-D DECODE_SAMSUNG=true
-D DECODE_LG=true
-D DECODE_SANYO=true
-D DECODE_SHARP=true
-D DECODE_DENON=true

And this reduces the .bin size by 2% !
Great !

Do you plan to commit this to the master ?

@crankyoldgit
Copy link
Owner

Excellent. Thanks for confirming it worked as intended.

Do you plan to commit this to the master ?

Yes. It is pending code review (PR #1013). Once that is done, it will be merged.

crankyoldgit added a commit that referenced this issue Jan 16, 2020
Allow users of the library to externally control which protocols are 
used/enabled/compiled without having to modify the `IRremoteESP8266.h` 
file.
i.e. `SEND_BLAH` & `DECODE_BLAH` can be controled with preprocessor 
compiler flags (see 
https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html)

Fixes #1012
crankyoldgit added a commit that referenced this issue Jan 30, 2020
_v2.7.3 (20200130)_

**[Features]**
- Allow protocols to be enabled or disabled with compiler flags. (#1013, #1012)
- Panasonic AC: Add Ion Filter support for DKE models. (#1025, #1024)
- Add support for sending Sony at 38Khz (#1029, #1018, #1019)
- auto_analyse_raw_data.py: Handle analysing messages with no headers. (#1017)

**[Misc]**
- Fix Coolix unit test errors when using Apple c++ compiler. (#1030, #1028)
- Fix Apple clang c++ compiler error in unit tests. (#1027, #1026)
- Improve/fix scraping of supported devices (#1022)
- Panasonic PKR series A/C uses DKE protocol. (#1020, #1021)
- Update NEC supported devices. (#1018)
- Add note to avoid GPIO16 on the ESP8266 for receiving. (#1016, #1015)
crankyoldgit added a commit that referenced this issue Jan 30, 2020
_v2.7.3 (20200130)_

**[Features]**
- Allow protocols to be enabled or disabled with compiler flags. (#1013, #1012)
- Panasonic AC: Add Ion Filter support for DKE models. (#1025, #1024)
- Add support for sending Sony at 38Khz (#1029, #1018, #1019)
- auto_analyse_raw_data.py: Handle analysing messages with no headers. (#1017)

**[Misc]**
- Fix Coolix unit test errors when using Apple c++ compiler. (#1030, #1028)
- Fix Apple clang c++ compiler error in unit tests. (#1027, #1026)
- Improve/fix scraping of supported devices (#1022)
- Panasonic PKR series A/C uses DKE protocol. (#1020, #1021)
- Update NEC supported devices. (#1018)
- Add note to avoid GPIO16 on the ESP8266 for receiving. (#1016, #1015)
@crankyoldgit
Copy link
Owner

The code changes referenced above have been included in the v2.7.3 release of the library.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants