dynamic-occupancy-grid-map icon indicating copy to clipboard operation
dynamic-occupancy-grid-map copied to clipboard

Folder structure

Open cbachhuber opened this issue 4 years ago • 5 comments

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?

cbachhuber avatar May 01 '20 16:05 cbachhuber

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?

TheCodez avatar May 01 '20 18:05 TheCodez

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 👍

cbachhuber avatar May 01 '20 20:05 cbachhuber

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.

TheCodez avatar May 01 '20 21:05 TheCodez

Sounds good :+1:

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.

cbachhuber avatar May 02 '20 07:05 cbachhuber

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.

TheCodez avatar May 02 '20 11:05 TheCodez