Change U8g2_Arduino directory layout

[olikraus]

The problem came up here:

https://arduino.stackexchange.com/questions/42889/uecide-linker-error-with-u8g2-library

Suggestion is, to remove the clib directory and put all c code into the parent directory of the clib folder.

1. Execute a git move in U8g2_Arduino as adviced in the link above, also move (!) the headers
2. Update create_release.sh: Change pathes
3. Update create_release.sh: Remove the sed commands

[per1234]

This seems to me like a bug in UECIDE rather than a problem with your library.

I see nothing in the Arduino Library Specification that would indicate any problem with putting source files in the clib subfolder. In fact, it specifically says:

The source code found in src folder and all its subfolders is compiled and linked in the user’s sketch.

It's not uncommon for libraries to have a structure like this. In fact it's quite useful for a complex library to be organized in multiple subfolders.

You might want to try out UECIDE before making any changes to see whether it has been improved in the last year. There was even some indication from the author last July this might happen:

I am working on improving the file finding routines for libraries - get it to work better for newer style libraries.

The only slightly screwy thing I notice in the library is this line:
https://github.com/olikraus/U8g2_Arduino/blob/master/src/U8g2lib.h#L50

#include <U8x8lib.h>

would be more correct as:

#include "U8x8lib.h"

[olikraus]

Thanks for your comment.

Actually also ArduinoDroid doesn't accept u8g2.

https://play.google.com/store/apps/details?id=name.antonsmirnov.android.arduinodroid2&hl=de

But you are right, it is a legal folder structure and I should test the new structure.

I have fixed the include statement.

[olikraus]

Indeed I do hesitate to change the folder structure, because I do not know whether the csrc folder will be deleted during Arduino IDE Library Updates.

[per1234]

It's strange because quite a few of the official Arduino libraries use a subfolder, including Wire, Ethernet, SD, Servo, Temboo, TFT, WiFi. Some of those are so commonly used I'm sure any IDE that imposed that restriction would have a lot of complaints.

I do notice that all the Arduino libraries except for Servo use a subfolder named utility (I believe this is a carryover from when the libraries were in the 1.0 library format). So I wonder if those IDEs have special handling only for the utility subfolder?

The Servo library uses a separate subfolder for each architecture. Perhaps that's what Majenko is complaining about here:

They made it more complex and woolly by adding this new library format for cross architecture libraries which is just plain nasty.

In fact there is no special cross-architecture format for Arduino libraries, it's just that the Servo library code does this:

#if defined(ARDUINO_ARCH_AVR)
#include "avr/ServoTimers.h"
#elif defined(ARDUINO_ARCH_SAM)
#include "sam/ServoTimers.h"
#elif defined(ARDUINO_ARCH_SAMD)
#include "samd/ServoTimers.h"
#elif defined(ARDUINO_ARCH_STM32F4)
#include "stm32f4/ServoTimers.h"
#elif defined(ARDUINO_ARCH_NRF52)
#include "nrf52/ServoTimers.h"
#else
#error "This library only supports boards with an AVR, SAM, SAMD, NRF52 or STM32F4 processor."
#endif

Majenko may have been confused because architecture subfolders were added to Arduino hardware packages in Arduino IDE 1.5.x.

I do not know whether the csrc folder will be deleted during Arduino IDE Library Updates.

I've been attempting some simulations of this by adding a folder to an installed library that's in the Library Manager index, then doing an update. What happens is the library folder removal process deletes the contents of the library folder but then for some reason fails to delete the library folder, then installs the update to a folder named arduino_nnnn where nnnn is a random number. Then you get the "Invalid library found in" warning for the leftover empty folder every time the libraries folders are scanned.

I'm not certain whether this same behavior would occur in real life rather than in my experiment, it's possible there is some sort of permissions error but then I'd expect the IDE to not be able to delete the folder I created, and that is not the case. It also doesn't occur when I create files, only folders.

Typically that arduino_nnnn folder behavior occurs when the library has a different name value set in library.properties and so Library Manager doesn't want to chance overwriting a custom library that just happens to have the same folder name as the one being installed, which is a good feature. In that case it doesn't delete the contents of the original library.

[olikraus]

Wow, thanks for spending so much effort on this topic. Actually u8g2 library structure is a carry over from the pre-1.5 structure, where we could have the c sources in the utility folder (as you mentioned). After reading the spec, i decided to rename the utility folder to csrc.

I will keep this issue open for a while. Maybe I find some time to investigate this further.
Thanks for testing the update procedure.

[olikraus]

I also did some tests. But finally I failed to import the modified U8g2 library via the "add zip lib" menu entry. The IDE complains, that the library already exists. Hmm.. I have never seen this message.

[per1234]

I think that error from "Add .ZIP Library" is normal when the library folder already exists. It's unfortunate because it means that feature can only be used to install a library, not update it. To update the user must delete the previous library installation, and at that point they might as well just do a manual installation of the new version. All that is easy enough for you or me, but can be challenging for people who are not experienced in working with computer file systems. This is the biggest benefit of Library Manager: Making it easy for the users to keep their libraries updated.

The statements in my previous reply were all related to Library Manager updates

[olikraus]

I think that error from "Add .ZIP Library" is normal when the library folder already exists. It's unfortunate because it means that feature can only be used to install a library, not update it.

Yes, correct. But this makes it almost impossible to test how the update mechanism will behave.

ok, then... I guess I will keep the folder structure as it is...

[olikraus]

ok... no further action here... closing