Closed beardedfool closed 5 years ago
What core version did you choose before compilation?
I think I cannot reproduce your problem (or correct me if I incorrectly read the configuration you provided). It compiles well with all core versions required by MQTT_TLS
Thanks for coming back to me so quickly Benzino.
I owe you an apology, I confused myself with versions as was trying a few
It's happening with 6.6.60, 2.6.x English, Sonoff 1Mb Firefox 64bit Quantum 69.02 on win10 1903
OK. I assume the 6.6.60
is a typo and you meant 6.6.0
. Now I can reproduce your problem.
Here are few tests I've performed (with features you choose):
#undef USE_SCRIPT_FATFS
- compilation error#undef USE_SCRIPT_FATFS
- compilation finished with successI think you have to contact Tasmota Dev Team to ask them question what is the reason. Contact them by discord chat at first.
It was a typo, Thanks for looking at that Benzino. I'll make them aware of this. I don't understand the output myself.
Regarding this document, scripter USE_SCRIPT_FATFS
needs SPI (which is off when "display support" is disabled). But even turning on USE_SPI
(Display Support enabled) cause errors during compilation.
Tested on Tassmota 6.6.0 and core version 2.6.x and 2.5.2.
@benzino77 Thanks for testing the permutations. Does this error occur with the latest development version (6.6.0.17)? We can follow up with Theo and Gerhard if it's still a problem.
Latest development with 2.6.x core compiles without any error.
So, it's fixed and users that need the Scripting will just need to use the latest code.
Thanks for testing.
I suggest that this Issue can be closed.
As far as I'm personally concerned that's ok as I've done what I need to. Thanks both.
Previous test shows that Tasmota 6.6.0 with core 2.5.2 and with additional custom parameter #undef USE_SCRIPT_FATFS
- compile with success (with same features), so probably that was fixed in latest dev branch.
@meingraham I've got a suggestion/proposition/feature request to change travis tests, or rather to extend them. What can be additionally tested are features which are not included in any ready to download bin file. For example MCP23017, Scripter, Full IR, etc. I think that the best way to do this is to prepare "special" platformio.ini
file just to test these features (there is no need to define additional feature "package" like FIRMWARE_SENSORS
, FIRMWARE_DISPLAYS
, FIRMWARE_KNX_NO_EMULATION
, etc.
@benzino77
Isn't the author of the PR supposed to make these kinds of tests before submitting the PR? Perhaps I'm not understanding what you are suggesting.
Mike
@beardedfool
This is the answer. I just could not identify which scripting features where added when (which Tasmota rev level). https://github.com/arendst/Sonoff-Tasmota/issues/6085#issuecomment-540524635
master branch is v6.6.0
and has not included the code for >F section in scripting.
@meingraham In general? Definitely YES!
What I'm trying to say is that, some tests should be performed by Tasmota project itself before PR is merged. There are two reasons (maybe more,but I identify those two as most important):
There is also a chance, that Theo can decide that given PR does not break anything just to look at the code, or do such tests on his side.
@benzino77
True, the are SUPPOSED to perform those tests. I'll discuss with Andre & Adrian.
Cheers.
Mike
@benzino77
We discussed options... but it seems that there is no good option.
One thought was to have a "test" image build to build everything into a 4MB image (even if never used). But this would fail because the limitation comes with the available iRAM limit which cannot be changed. Enabling everything would exhaust the iRAM as the linker knows to be available and the compile would fail.
Trying smaller builds with permutations of different options would then be a problem as to which permutations and maintaining the build definitions as new features are added. Doing this would also increase the time Travis takes to perform all the tests thus impacting how often the code could be compiled.
And also, some problems are not due to developers not testing properly. Sometimes a problem in a driver comes when changes are made elsewhere by some other developer which inadvertently breaks another feature. So, I retract what I said above... at least as a blanket statement.
Unfortunately, it seems we have the situation we have and cannot really improve. We just have to deal with the occasional issue when a user compiles a custom binary.
Cheers!
Mike
I suspected that this is not trivial. Number of permutation is, I think, the main problem and there is no simple solution. Anyway it was only suggestion ;)
Mike, thanks for your commitment!
Hi,
It's probably me, not you but in case it's useful - I was trying to compile the development branch with scrips, webgui