Git submodules with Cinder & TinderBox?


Hi all. I’d like to use some blocks in a project and have them set up as git submodules. Is there a recommended way of doing this? I’m currently seeing two issues when trying to set up this via TinderBox…

One issue is that even when a block in CINDER_ROOT/blocks is a git repo, the Install option for “Git Submodule” is disabled. How is this supposed to work, and/or any idea on why it’s disabled here?

The other issue is that it seems like TB will only look in CINDER_ROOT/blocks for blocks, and there’s no way to have it scan other locations (like PROJECT_ROOT/blocks). I’m trying to have my blocks be inside the project folder so things are encapsulated, and so that I can check any blocks that are used across projects out to different commits, instead of having that block exist “globally” in CINDER_ROOT/blocks such that I’d have to change the commit it’s checked out to whenever I switch between projects with different requirements.

To put it more visually, I’d like to have a folder structure something like this. Is this possible currently, and if not is there interest in adding support for something along these lines to TinderBox?

- blocks
  - Cinder-OpenCV3 (git repo)
  - Cinder-Runtime (git repo)
- projects
  - MyDopeProject (git repo)
    - src
    - blocks
      - Cinder-OpenCV3 (git submodule of MyDopeProject)
      - Cinder-Runtime (git submodule of MyDopeProject)
  - MyNotAsCoolProject (git repo)
    - src
    - blocks
      - Cinder-OpenCV3 (git submodule of MyNotAsCoolProject)
      - Cinder-Runtime (git submodule of MyNotAsCoolProject)



this is a limitation of TinderBox that I wish would have been addressed by now, but sadly isn’t. As you found out, TinderBox will only look inside the blocks folder of the selected Cinder repository.

I’m not sure what the Git submodule option in TinderBox does, so I can’t help you there. Edit: maybe this option is only available if the block’s author has provided a github URL to the block description.

My strategy for using blocks in projects, is to have a blocks folder in my project’s root to which I add blocks as submodules, exactly the same as your approach. To then add the blocks to my project, I open the block’s XML description and use it to add the headers, source files and paths to my project manually. This takes a few minutes per block, but it’s annoying and error prone.

It would be awesome if TinderBox would search up the directory tree for a blocks folder and add those blocks to the selection list as well. This would work if Cinder itself is also a submodule of your project (which it always is in my setup, because one project may depend on a different version of Cinder than another project). With a folder structure like the following, TinderBox would then be able to find the additional blocks:

  - cinder (submodule)
    - blocks
      - Cinder-OSC (default Cinder block )
      - etc.
  - blocks
    - Cinder-OpenCV3 (submodule)
    - Cinder-Assimp (submodule)

I guess one reason this approach has not been tried or supported, is that it potentially could cause conflicts when a block is present in multiple locations, if there are multiple versions of the same block or if there are different blocks with the same name.

You could create an issue at GitHub for TinderBox-Win and/or TinderBox-Mac and work along with the devs to come up with a solution. Edit: you can find the correct Git repo in @rich.e 's post down below.



Thanks for the reply, Paul. I had the same thought about the git url being empty, but I’ve checked a few blocks (Runtime, ImGui, OpenCV3) and they all have urls but show as disabled. When I get some time I’ll try to dig in and/or post something on the repo, both on that specific issue and the broader topic :+1:t3:


Actually I think the repo we want to congregate issues at is Also, we have an issue open for the alternative paths feature (see: Support alternative CinderBlock location). Also, see this PR that is a partial solution.

As per your first question, I think the expectation is that the app that you make itself would be a git repo, and then TinderBox would clone a submodule of the cinderblock (Runtime in your screenshot) as part of the app’s git repo. In other words, this checkbox would be ticked:

Though I’d agree that this is a bit confusing, I think it tripped me up at one point too. Perhaps work could be done here in conjunction with adding support for alternative block paths.

Concerning contributions to TinderBox source, these are most certainly welcome. I think many of us have converged on setting up our projects with the same structure that you’ve provide, so it’d especially be great IMO if we could make TinderBox facilitate that.