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

Dependency management question #122

Open
willyd opened this issue Aug 7, 2015 · 1 comment
Open

Dependency management question #122

willyd opened this issue Aug 7, 2015 · 1 comment
Milestone

Comments

@willyd
Copy link

willyd commented Aug 7, 2015

Hi,

I looked at your heterogenous package retreival solution and it is very close to what I was looking for. Although your documentation is very helpful on understanding the design of the solution I am having a hard time to understand how to create packages from my own or third party code.

From what I understand, every package must have a package descriptor defined in a package.cmake located in the root directory of the package. Is this correct?

Let's take the case where I have a package A that depends on B. Both are downloadable archives from github. Should both archives include a package.cmake file in the root directory? With package A listing package B as a dependency? So that when I pull the package A, package B gets pulled automatically?

If I have another package C on which I don't have control. Can I somehow pull the package and "inject" a package.cmake file in the source folder once the package was downloaded and the archive extracted?

Thanks

@toeb
Copy link
Owner

toeb commented Aug 7, 2015

Hi @willyd

To answer your first question: yes&no . Every package has to have metadata available which contains information on identity and content and depedencies etc. Much of this is however inferred if you use git,github,bitbucket etc as a package source (it depends on the package soruce on how much information can be inferred) So you do not need a package.cmake or package.json file but I do recommed that you have one.

Here is a distinction that is important in cmakepp package resolution & retrieval != project management & dependency management. And dependency management is not as well tested as resolution and retrieval.

For some more information on how dependency management works you can also look at the tests in
https://github.com/toeb/cmakepp/tree/master/tests/package/project_tests

cmakepp is actually a package manager which automatically can resolve and retrieve the dependency graph like you thought.

you can also create a "wrapper" package for other packages you just need to create a single package.cmake which has a dependency to the files of the package in question and decorates it with the metadata neceassary for your purposes.

I already tried everything and it worked however I do not have samples or documentation yet as its still work in progress.

If you have the time and the interest you could learn it and work with it - I am always happy to answer questions. However I did not publicize the depnendecny management aspect of cmakepp yet because it is not yet totally complete and not documented well enough yet (the documentation you can find is still in draft form)

however the features which are already part of cmakepp contains the following:

boolean satisfiablity dependency solver (allows cyclic dependencies etc)
dependency retrieval
hooks for all kind of package events (on materialize, on load, on instal, on uninstall, before dematerialize, on ready (all dependencies materialized) ...)
cli for package management and package descriptor mangement
project lifecycle management...

cheers
toeb

@toeb toeb modified the milestone: Stable Feb 2, 2016
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