Proposal to Separate SSD1306 Component to a Standalone Repository

[Krzyshio]

Hi @nopnop2002,

I've been using your SSD1306 Driver for esp-idf and find it very useful. However, I noticed that the SSD1306 driver is bundled together with numerous examples within the same repository.

Although these examples provide valuable context, I suggest separating the SSD1306 driver into its own dedicated repository. This would make it easier for developers to integrate the driver into their projects, possibly as a Git submodule, without the necessity of cloning the entire current repository.

Separating the driver into its own repository could streamline its adoption by other developers and make it more accessible.

Please consider this proposal and let me know your thoughts.

Thanks for your time

[nopnop2002]

I noticed that the SSD1306 driver is bundled together with numerous examples within the same repository.

Drivers are only here.

All samples use this.

https://github.com/nopnop2002/esp-idf-ssd1306/tree/master/components/ssd1306

You can only clone this directory.

This has the same result as putting just the driver in a separate repository.

$ mkdir your_directory
$ cd your_directory
$ git init
$ git config core.sparsecheckout true
$ git remote add origin https://github.com/nopnop2002/esp-idf-ssd1306
$ echo components >> .git/info/sparse-checkout
$ git pull origin master
$ ls -R
.:
components

./components:
ssd1306

./components/ssd1306:
CMakeLists.txt     font8x8_basic.h  ssd1306.h      ssd1306_spi.c
Kconfig.projbuild  ssd1306.c        ssd1306_i2c.c

[Krzyshio]

Thanks for your quick response and for the explanation on how to use sparse checkout to isolate the driver.

However, the method you suggested lacks one important feature for developers, that is direct linkage to your original repository.

By using your driver as a standalone repository or as a Git submodule, each project that uses your driver can easily reference back to the original repository, allowing other developers to understand where the driver came from and perhaps contribute to its development.

Furthermore, with a direct link to the original repository, developers can watch for updates, issues, and discussions regarding the driver, keeping them in the loop for any potential changes or improvements. This would not be possible with the current method you've suggested as the link between the original repository and the cloned directory is lost.

Lastly, with a Git submodule or standalone repository, updating to the latest version of the driver is more straightforward. Instead of manually performing the sparse checkout for newer commits, developers can use Git's built-in mechanisms to update submodules, ensuring they have the latest version with less manual intervention.

I believe these benefits justify considering the usage of a standalone repository or Git submodule for your SSD1306 driver. Please let me know your thoughts on this.

[nopnop2002]

ESP-IDF behaves differently depending on the version.

V4.X and V5.X are less compatible and should be considered completely different.

We made many fixes to make it work using single-source for both V4.X and V5.X. However, in some repositories the differences were so great that it was necessary to split the branches.

Perhaps V5.X and V6.X will be completely different things

In this case, create a branch in the repository and manage the source for each version.

Luckily, SSD1306 can currently provide the source code in one branch, but we may need to separate the branches in the near future.

Even if we used a standalone repository for our SSD1306 driver, we still need to separate the branchs.

V4.X can be used until July 2024. Developers using V4.X may require a set of non-latest versions of the driver and sample code at the same time. Only developers using V6.X will need the latest versions of the drivers and example code.

[Krzyshio]

Despite these challenges, I still believe that separating the SSD1306 driver into its own repository and using Git submodules could be beneficial. This would not eliminate the need for maintaining separate branches for different ESP-IDF versions, but it could simplify the process of integrating your driver into other projects.

When your driver is used as a Git submodule in a project, developers can easily switch between the branches in your repository to match their ESP-IDF version. This allows them to work with the version of your driver that is compatible with their ESP-IDF version, while also maintaining a direct link to your repository.

Additionally, the use of Git submodules can make the process of updating to the latest version of your driver much simpler. Instead of manually performing the sparse checkout for newer commits, developers can use Git's built-in mechanisms to update the submodule, ensuring they always have the latest compatible version with less manual intervention.

[digiexchris]

I think you could accomplish both just by having the component live at the top level of this project, and have the examples live inside an examples directory inside that component. That's what many components do in the idf-component-registry.

mkdir examples mv examples/ mv examples/components/ssd1306/ ./ rmdir examples/components

done :D

I agree with making it a top level component in this repository, right now I have to manage it by cloning it somewhere else, and have my build scripts copy the component in, and make comments saying which version it is and where it came from. Less than ideal, it breaks with how most components are distributed right now.

[nopnop2002]

@digiexchris

I would like you to show me the specific directory structure so that there is no misunderstanding.

[digiexchris]

here's a good example https://github.com/eldendiss/DendoStepper

which you can install by either cloning directly into your project's components directory, or using the idf.py add-dependency tool, or downloading and unzipping the files. The includes directory is just specified in the cmakelists file, so you can put it anywhere even the current directory.

On Mon, Dec 18, 2023 at 8:11 PM nopnop2002 @.***> wrote:

@digiexchris https://github.com/digiexchris

I would like you to show me the specific directory structure so that there is no misunderstanding.

— Reply to this email directly, view it on GitHub https://github.com/nopnop2002/esp-idf-ssd1306/issues/22#issuecomment-1861990534, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMZQGXIUES4HM5BT3UPW7LYKDZUHAVCNFSM6AAAAAAYSNM3QCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRRHE4TANJTGQ . You are receiving this because you were mentioned.Message ID: @.***>

[nopnop2002]

@digiexchris

Thank you for your quick response. I'll consider it.

[nopnop2002]

I saw this. https://github.com/eldendiss/DendoStepper

This directory structure is similar to that commonly found in Arduino libraries.

On the other hand, the official esp-idf sample makes extensive use of component directories.

./wifi/antenna/components
./ethernet/enc28j60/components
./ethernet/basic/components
./bluetooth/nimble/throughput_app/blecent_throughput/components
./bluetooth/esp_ble_mesh/ble_mesh_coex_test/components
./bluetooth/esp_ble_mesh/aligenie_demo/components
./system/unit_test/components
./system/console/advanced/components
./system/gcov/components
./peripherals/spi_master/hd_eeprom/components
./peripherals/dedicated_gpio/soft_uart/components
./peripherals/dedicated_gpio/soft_i2c/components
./peripherals/dedicated_gpio/soft_spi/components
./peripherals/gpio/matrix_keyboard/components
./storage/custom_flash_driver/components
./build_system/cmake/plugins/components
./build_system/cmake/import_prebuilt/prebuilt/components
./build_system/cmake/import_lib/components

[digiexchris]

yes and that works fine, as long as the cmakelists.txt file in the root of the repo resolves those paths correctly. The espressif toolchain has complicated rules to resolve nested cmake files. If you provided a cmakelists.txt in the root of this repo, that would solve the issue for most.

[bullestock]

It is easy enough to use this project as a submodule in an ESP-IDF project:

cd components
mkdir ssd1306
cd ssd1306
git submodule add https://github.com/nopnop2002/esp-idf-ssd1306.git

Now, in the top level CMakeLists.txt, add

set(EXTRA_COMPONENT_DIRS
    ./components/ssd1306/esp-idf-ssd1306/components/ssd1306/)

[nopnop2002]

There are two ways to use this library in your own project.

The first way is the method described by bullestock. This method allows you to use this library in all your projects.

The second way allows you to enable this library only for specific projects. In this case, no changes to CMakeLists.txt are required.

cd $HOME
git clone https://github.com/nopnop2002/esp-idf-ssd1306
cd esp-idf-ssd1306
cp -r components your_project_directiory

In either case, don't forget to remove the sdkconfig present in your_project_directiory.

cd your_project_directiory
rm sdkconfig