Maybe sol2 will support the package Manager from the conan ?
kotbegemot
All 34 comments
sol2 comes with CMake support. It's also a header only library. I don't know what else I need to do to support Conan.
ThePhD
on 22 Dec 2018
If there's a recipe for a conan . The ability to add sol2 support in one line in the file will be very cool
kotbegemot
on 22 Dec 2018
Someone talked about making one or made one, but I don't keep up to date with the latest build systems and package managers, sorry!
ThePhD
on 22 Dec 2018
Maybe it'll help . https://conan.io/
kotbegemot
on 22 Dec 2018
kotbegemot
on 22 Dec 2018
I think if there's a person who wants to do it, they can make a bincrafters repo and we can link it in this repo.
eliasdaler
on 25 Dec 2018
Yeah this looks like a lot of work for something I have no intention of using ever...
Pull requests welcome, until I one day decide that sinking myself into Yet Another Crappy Build And Package System is worth the effort.
ThePhD
on 25 Dec 2018
I will write the conan recipe, it is not difficult at all if you know the tool.
EDIT: I am new the sol2, but the recipe should be pretty minimal 馃槃
Lnk2past
on 2 Jan 2019
Bless your soul 馃檹
ThePhD
on 2 Jan 2019
Sorry for such a terrible delay on this, I am working on this now
Lnk2past
on 27 Mar 2019
@Lnk2past Just make sure when you work on it, you do the work relative to the sol3 branch!
ThePhD
on 27 Mar 2019
@ThePhD Sure thing. The conanfile.py will live on the sol3 branch, but for starters it will point to the 2.20.5 release. Once I create that release, I will move to update it to produce a "git-develop" release from the sol3 branch.
I have a question though about naming/versioning: is the idea that sol3 will be the name of a new product? Or is that just the "codename" for the sol2-v3.0.0 release? Just trying to wrap my head around how to name these releases/repositories.
As far as what the package contains, to begin I am going to have it capture only the headers (and not try to do anything with CMake up front) and it will by default grab the sol directory, with an option to grab the single directory instead. If you would like the default to be single let me know. Obviously in sol3 this would change to point to the include directory instead.
Lnk2past
on 27 Mar 2019
I would greatly prefer you point to the proper sol3 directories first (and encourage sol3 use); it's stable and ready for production use. (Just lacking in docs, bwuh.)
sol3 is the "next" version of sol2. They should all be called "sol2" in repositories, mostly because other people probably will want to take the name "sol" and I don't want to be in that sandwich. I use sol3 as a convenient shorthand for sol2-v3.0.0, and as M A R K E T I N G H Y P E .
ThePhD
on 27 Mar 2019
Gotcha, I will point from the sol3 branch and get things started with a 3.0.0-unstable (or -dev, or -whatever you really want to suffix it with) version. I should have everything ready in the next few days.
Though I'll get everything setup, it should probably be you, being the owner/author and all, that pulls the trigger on getting everything officially uploaded/owning the deployment repositories. This would mostly be a one-time thing for you to setup, as I am also adding in the hooks to deploy automatically via TravisCI (or AppVeyor, if you prefer). When I have everything ready I can provide you with the detailed instructions to make sure that everything is pushed properly.
Lnk2past
on 27 Mar 2019
We should already have Travis and Appveyor running. The sol3 builds are now clean, as far as those 2 CI systems are concerned.
ThePhD
on 27 Mar 2019
Yea, I saw both, so I was not sure if you wanted to deploy through one or the other. Whenever you tag a release Travis (or AppVeyor) would pump that release over to bintray, that way you do not have to manually do it every time.
Lnk2past
on 27 Mar 2019
Ooooh, that's what you mean.
Yeah, do whatever makes you happy. I'm not the expert with these things. :D
ThePhD
on 27 Mar 2019
Is it possible to build support for a stable branch too? @Lnk2past
kotbegemot
on 30 Mar 2019
The stable branch has been cannibalized by sol3.
ThePhD
on 30 Mar 2019
@ThePhD Support for version 2 will not be ?
kotbegemot
on 30 Mar 2019
No. I have no intention of supporting multiple versions of a thing I am not paid for. That being said, sol2's latest v2.x.x are still all freely available and still work fairly well with C++14, but I'm not going to be working on adding any features to it.
ThePhD
on 30 Mar 2019
Recipe for Canon made.
It started with the version of sol2 2.20.6.
I will be happy to suggestions for improvement.
https://github.com/jinncrafters/conan-sol2
kotbegemot
on 23 Oct 2019
@kotbegemot Hey, thanks for the first draft! I haven't had time to look, but maybe soon.
ThePhD
on 9 Nov 2019
I will try to add the latest version of the library soon .
kotbegemot
on 9 Nov 2019
Works great as long as I'm also linking/including the core lua libraries. Thank you! Maybe add something to the README (in the conan recipe) that this needs to be done still?
chao-mu
on 15 Nov 2019
Maybe I can fix it. Tell me the details. @chao-mu
kotbegemot
on 15 Nov 2019
The issue I believe is that sol has a dependency on the lua library, but the recipe doesn't include that dependency. However, I don't think there is an official conan recipe for lua, so it may be a lost cause doing more than just saying "you need to provide lua yourself".
chao-mu
on 16 Nov 2019
I just create a PR for the conan index center so that the package will just exist in future via conan
https://github.com/conan-io/conan-center-index/pull/1220
I used version 3.0.3 since it was not obvious to me if 3.2.0 is an official release, I think the lastest stable label is at 3.0.3
it usually takes some tweaks and a few days until such PRs are accepted,
please review and add a comment if you see something to improve.
a4z
on 30 Mar 2020
Use head. All the time. Literally, pull from the latest. Never from a tagged version. If it requires a tagged version, let me know so I can start slapping tiny minor revision tags on everything.
But please, always live at head.
ThePhD
on 30 Mar 2020
always from head is not doable for this kind of packaging,
There are many situations where you need to have the same version no matter if I build today, or tomorrow, a package. The outcome must be the same. Therefore the source must be the same, and a checksum for the source must be stored somewhere (else).
And for this a download link is needed. And sem versioning for some other checks, because git shas sort so bad.
And I know the talk from Titus, yes, but there are other industries and scenarios also ;-)
a4z
on 30 Mar 2020
sol2 is now available via conan center :-)
https://github.com/conan-io/conan-center-index/commit/79541efd967e9a07704a96f63444681c3dbfaaf7
and
https://conan.io/center/sol2/3.0.3/?user=_&channel=_
next step is to add the last 2.x release for those who are pinned to c++14,
and then the 3.2 release
(there can only be one version update per PR)
after this I hope there will be regularly tagged versions of sol2 so the recipe can be updated from time to time to the latest and greatest sol2 experience :-) but this is up to @ThePhD to decide
a4z
on 14 Apr 2020
I'll absolutely help put out tagged releases to help with this. Thank you so much!
ThePhD
on 14 Apr 2020
I think you can close this now :-)
the latest 2.x for C++14 apps, and 3.2 are now at conan
https://github.com/conan-io/conan-center-index/tree/master/recipes/sol2
if nothing changes in the build logic with CMake, adding new versions is as easy as adding the URL and the checksum in this file (and therefore tags are needed ;-)
https://github.com/conan-io/conan-center-index/blob/master/recipes/sol2/3.x.x/conandata.yml
a4z
on 5 May 2020
WOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO! 馃帀
ThePhD
on 5 May 2020
Related issues
elfring
路
10Comments
morsisko
路
3Comments
patlecat
路
7Comments
hmenke
路
6Comments
cgloeckner
路
3Comments
Most helpful comment
I will write the conan recipe, it is not difficult at all if you know the tool.
EDIT: I am new the sol2, but the recipe should be pretty minimal 馃槃