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

Folder structure #48

Open
cbachhuber opened this issue May 1, 2020 · 5 comments
Open

Folder structure #48

cbachhuber opened this issue May 1, 2020 · 5 comments

Comments

@cbachhuber
Copy link
Contributor

All source code of this repository resides in folder dogm. From other repositories, I'm used to having source code and e.g. the top-level CMakeLists.txt in the root of the repository. Let's have a quick pros and cons overview of the current solution and moving everything from dogm/ into the root of this repository:

Sources in sub-folder dogm/:

  • File list on the github starting page is nice and short, gives direct access to readme

Sources in root:

  • Easier navigation, as we are usually working with source files
  • Makes professional repository configuration such as the .clang-format file or CMakeLists.txt directly visible to visitors
  • Direct IDE support: when you open the repository with an IDE that supports CMake (e.g. CLion or VS Code), it will automatically configure your project and offer compilation and execution of targets

I see advantages in moving the sources one level up and removing dogm/. Am I overlooking something or do you agree?

@TheCodez
Copy link
Owner

TheCodez commented May 1, 2020

Given that I want to have fully fledged ROS support at some point with multiple subprojects this isn't really a viable option but I can definitely understand your points.
However having the .clang-format in the top level directory seems like a good idea so the format can be applied to every project.

I'm not sure what's the best way here. Should the ROS support stay in its own branch or should all ROS projects be merged into the master branch.
Pros:

  • Easier to maintain the ROS support (having the DOGM source inside the top level folder would make maintaining even harder given that we need multiple ROS projects).
  • ROS support isn't "hidden".

Cons:

  • Not everyone wants to use ROS and this clutters the repo for them.

What do you think?

@cbachhuber
Copy link
Contributor Author

True, with ROS things do look different. I advise against a separate ROS branch. As you say, that's not nice to maintain and not visible.

As a middle ground, it should be possible to add a folder ros to the root of this repo on master, and put all ROS-related things in there, right? That doesn't clutter, and ROS is properly visible on master. Sources currently in folder dogm should stay there in that case.

One could also argue that the dogm library is one product and ROS support another. With this logic, two repositories make sense. In the ROS repository, you could import the dogm library as a git submodule.

I see the above two options the best ways to go ahead; which one shall it be? 😉

Good idea with .clang-format 👍

@TheCodez
Copy link
Owner

TheCodez commented May 1, 2020

One could also argue that the dogm library is one product and ROS support another. With this logic, two repositories make sense.

It surely makes sense. Will have to think about it a bit more.
Having a ros folder sounds like a good way if we stick to having a single repo.

Let's keep this issue open for now.

@cbachhuber
Copy link
Contributor Author

Sounds good 👍

Slightly related to folder structure: what are your criteria for removing the WIP disclaimer from this repository? Maybe you want to open an issue for gathering those.

@TheCodez
Copy link
Owner

TheCodez commented May 2, 2020

Good question!
The reason for having the disclaimer was to prevent people complaining that the implementation isn't working. Now that it's working for quite some time, we could remove the WIP notices. However, I would keep a disclaimer noting that currently there are no efforts to keep any backwards compatibility as the API is still evolving.

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

No branches or pull requests

2 participants