Hi Hannah, Your solution here was a very good one. I don’t think I sent you an update on this. It greatly reduced the number of INDI related recipes that I needed to have from about 24 down to 3. And now it works nicely.
Thanks, Rob > On Jan 31, 2019, at 3:58 AM, Hannah von Reth <han...@von-reth.de> wrote: > > Hi Robert, Hi Jasem, <> > > <> > I'd suggest to add a CMakeMakefile.txt to <>https://github.com/indilib/indi > <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:rlanca...@gmail.com> > Sent: 31 January 2019 04:24 > To: Hannah von Reth <mailto:vonr...@kde.org>; kde-windows@kde.org > <mailto:kde-windows@kde.org> > Cc: Jasem Mutlaq <mailto:mutla...@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 > <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 > <https://github.com/rlancaste/kstars-on-osx-craft> > > And my Mac versions of the recipes are here: > > https://github.com/rlancaste/craft-blueprints-kde > <https://github.com/rlancaste/craft-blueprints-kde> > > We probably will have the issues worked out by next week. > > > Thanks, > > Rob
