-
Notifications
You must be signed in to change notification settings - Fork 65
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
Proposal to Separate SSD1306 Component to a Standalone Repository #22
Comments
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.
|
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. |
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. 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. |
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. |
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 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. |
I would like you to show me the specific directory structure so that there is no misunderstanding. |
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
<#22 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABMZQGXIUES4HM5BT3UPW7LYKDZUHAVCNFSM6AAAAAAYSNM3QCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRRHE4TANJTGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Thank you for your quick response. |
I saw this. 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.
|
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. |
It is easy enough to use this project as a submodule in an ESP-IDF project:
Now, in the top level
|
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
The text was updated successfully, but these errors were encountered: