Craft recipes with more than one target

[Hannah von Reth]

Its definitely possible to have multiple targets in a blueprint.
Most blueprints have.

You can set a version by calling "craft --set version=master kstars"

To manage syncronised releases have a look on https://github.com/KDE/craft-blueprints-kde/tree/master/extragear/kexi or frameworks.
The version.ini holds all targets, and the blueprints just call self.versionInfo.setDefaultValues() .

Cheers,

Hannah
________________________________
From: Kde-windows <kde-windows-bounces at kde.org> on behalf of Robert Lancaster <rlancaste at gmail.com>
Sent: Thursday, January 31, 2019 2:48 PM
To: Hannah von Reth
Cc: kde-windows at kde.org
Subject: Re: Craft recipes with more than one target

Hi Hannah,

Thank you for the quick reply.  I will discuss that solution with Jasem.

We do want to have a stable build certainly as you state but we also want a “latest” build which uses the latest INDI code downloaded from git, since we not only need craft to build stable releases of the software, but also need it for developing the software on macs, as well as distribution of the latest build for testing purposes and for people who want to play with the latest source code.  As of now they are two separate recipes, for example indiserver and indiserver-latest, but I would like to combine them.  I have successfully used “latest” as a version “number” in craft and can probably use that to modify the recipe to decide whether to use the stable tarballs or download from git.  I hope to reduce the number of recipes for INDI from 24 down to 12, 2, or maybe 1.

Thanks,

Rob

On Jan 31, 2019, at 3:58 AM, Hannah von Reth <hannah at von-reth.de<mailto:hannah at von-reth.de>> wrote:


Hi Robert, Hi Jasem,


I'd suggest to add a CMakeMakefile.txt to https://github.com/indilib/indi and provide cmake options to enable/disablemodules.
Alternatively those modules should become real modules and reside in their own repository.
The current layout it really uncommon.

I also recommend to use tarballs for stable builds, this would eliminate the need to clone the source 12 times.

Cheers,

Hannah




From: Robert Lancaster<mailto:rlancaste at gmail.com>
Sent: 31 January 2019 04:24
To: Hannah von Reth<mailto:vonreth at kde.org>; kde-windows at kde.org<mailto:kde-windows at kde.org>
Cc: Jasem Mutlaq<mailto:mutlaqja at ikarustech.com>
Subject: Craft recipes with more than one target



Hi Hannah,



I have a question about whether craft is capable of doing something.  In my quest to build Mac craft recipes for building KStars, I have made a number of recipes.   One set of them though, seems a little silly.  I had to make one recipe for building indiserver, one for making indiserver 3rdParty, and one for each of the Indi driver libraries (there are 10 of them) which are dependencies of the indiserver 3rdParty build.  Each recipe is fairly easy to write since they are almost identical.  It also makes some sense because people may want to install libsbig but not install INDI, since they might want to use it for something else.  But there are a couple of issues with that.   First, there are at least 12 recipes to maintain, which are all coming from the same source.  Each of these 12 recipes uses the exact same repository:  https://github.com/indilib/indi.   Another issue with that is file size and download speed, because the download of indi for each recipe is 481 MB apiece.  That gives a total of 5.6 GB for the whole INDI build.  And when INDI changes they would all need updates. . .



So I could see a couple of solutions to this:



One might be to download the repository once, and then somehow point all of them to the same source folder.  This would have the advantage of reducing the file size, but still allowing a user to build whichever part of indi they like as well as build it all with the craft dependency structure as I currently have them organized.  But I’m not sure how to change this setting to make all of them use the same folder.  Right now of course each one downloads to its own source folder based on the package name.



Another one would be to somehow write the 3rd party recipe to build all of the libraries in addition to the 3rd party build.  Is there a way to do something like this, where you can specify more than one source folder, so that it runs the configure, make, and install steps for each one?  The following will not work currently because it will just do the second one.

self.targetInstSrc['Latest'] = "3rdparty/libaltaircam"

        self.targetInstSrc['Latest'] = “3rdParty"



Another solution that I found is that I can specify from the command line the source folder, so that in my script, I might be able to say:

craft -vvv -i --src-dir ~/AstroRoot/kstars-craft/download/git/libs/indiserver3rdParty-latest/3rdparty/libfishcamp indiserver3rdParty-latest

craft -vvv -i --src-dir ~/AstroRoot/kstars-craft/download/git/libs/indiserver3rdParty-latest/3rdparty indiserver3rdParty-latest

But to do it this way, I cannot specify the targetInstSrc folder because it will try to look in a subfolder when I specify src-dir



What would be the best approach, or do you have a better one?



In other news, I almost have the KStars recipes finished.  Most of the things we need are now building well.  This  week I wrote the code that we need to build KStars using those recipes and make a repository for it.  We can now successfully build a dmg that works almost as well as the old scripts that used homebrew do.  There’s just a few more things to iron out.  If you are interested, the build script is here:



https://github.com/rlancaste/kstars-on-osx-craft



And my Mac versions of the recipes are here:



https://github.com/rlancaste/craft-blueprints-kde



We probably will have the issues worked out by next week.





Thanks,



Rob










-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-windows/attachments/20190131/b9abac8c/attachment-0001.html>