Git Product home page Git Product logo

Comments (4)

mosra avatar mosra commented on April 28, 2024

Great idea! I did similar thing with my previous projects and this is also similar to how Qt5 sources are managed (with great success). However, some people say that submodules are too hard to use and prone to data loss, so I wanted to avoid them for general use case if possible. Magnum (and also all other projects) already uses submodules, there is toolchains submodule which contains stuff for cross-compiling, but it is fully optional and is not needed for common usage.

Instead of adding submodules into magnum repository I would rather have some kind of "superproject" (e.g. magnum-bundle repository) which would contain just the submodules for corrade, magnum, magnum-plugins, magnum-integration, magnum-examples and some tiny bureaucracy (readme/license) stuff on top, but without any actual code (similar to e.g. https://github.com/qtproject/qt5 or https://github.com/harr999y/boost).

I personally hope that CMake would be able to handle this and compile/install everything at once, which will be great. I'll do some research about CMake subprojects/modular projects and will see what can be done.

from magnum.

svenstaro avatar svenstaro commented on April 28, 2024

I think you should not go with a super project but merely put all the required repos for magnum into this repo as submodules. examples and plugins and such do not really need to be linked. Other projects also do it pretty much like this rather often.

I think making a super repo is unnecessarily abstract and also hard for you to manage as you need to pull in new deps into the super repo manually after working on one of the specific other repos outside the context of the super repo.

CMake is able to do all of this wonderfully if you switch to using PROJECT_SOURCE_DIR and PROJECT_BINARY_DIR.

So use submodules buy only for making this easier to build but not for putting unrelated things under the same umbrella. Use an organization for that!

Refs:

from magnum.

mosra avatar mosra commented on April 28, 2024

I'd rather not put Magnum dependencies into magnum repository, as for nearly every change in Corrade I would also need to update the submodule in magnum to make it compilable. It would add too much noise and maintenance overhead, the occasional noise with updating Find*.cmake modules in each repo is already annoying enough.

I thought that the super repo would handle just that one use case when you want to do a quick "one-click" install without too much hassle. It would be then just a matter of git clone --recursive or git pull && git submodule update, then you call cmake and cmake --build . --target install and you are done with Corrade, Magnum and all selected plugins/examples/libraries in single step.

This will be best for users who just want to use the project. Any actual development on the library itself is painful with submodules and makes some things unnecessarily complicated (e.g. pulling upstream changes where you want to update just one project, issues when you have uncommited changes in submodule...), so the preferred way for developing the library itself would still be to clone all repos separately.

Thanks for references for the PROJECT_* variables, I'll switch to them.

from magnum.

mosra avatar mosra commented on April 28, 2024

After two hundred years I was finally able to implement support for CMake subprojects. Sorry it took so long.

What I've done: there is no "superproject" repository anywhere, it's completely up to you as the user how you set it up -- just a matter of putting all the needed repos into your project (Git submodules or whatever) and then adding them in correct order using CMake's add_subdirectory() command. All the magic is then done by find_package(Magnum) and others, which recognize the subprojects and makes them available in your project tree. The same of course works for Corrade, plugin, integration, extras and example repositories too.

The Getting Started Guide was rewritten in 4fdf96d to prefer this approach, as it is much simpler to do (and to explain, too).

from magnum.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.