On Mon, Feb 8, 2016 at 2:44 PM, Sandro Andrade <[email protected]> wrote: > On Sun, Jan 31, 2016 at 8:42 PM, Aleix Pol <[email protected]> wrote: >> On Mon, Feb 1, 2016 at 12:30 AM, Albert Astals Cid <[email protected]> wrote: >>> El Tuesday 26 January 2016, a les 10:15:47, Andreas Cord-Landwehr va >>> escriure: >>>> On Monday 25 January 2016 21:48:27 Albert Astals Cid wrote: >>>> > El Sunday 24 January 2016, a les 16:50:18, Andreas Cord-Landwehr va >>>> >>>> escriure: >>>> > > * it looks strange to me that in minuet/cmake/ there are Config-files >>>> > > for >>>> > > the 3rd-party library drumstick. My understanding was that such Config >>>> > > files should only be shipped with the respective library (maybe someone >>>> > > with a deeper CMake-knowledge can comment?) >>>> > >>>> > If upstream ships a cmake file awesome, but if not then we have to find >>>> > it >>>> > having our own cmake file. >>>> >>>> Absolutely, but shouldn't that be find-files then instead of config-files? >>>> I always had the perception that those are quite different. >>> >>> Right, it most probably be a Find file not a Config file, as far as I >>> understand it Config files are mostly for projects that ship the cmake file >>> as >>> part of their install. >>> >>> Can someone with more cmake knowledge comment? >> >> Yes, the idea is that *Config.cmake files should be distributed by the >> framework itself, otherwise you need to find it. It probably works >> though, because such things are seldom checked within cmake though. >> >> I suggest turning it into a normal Find*.cmake file. Or get Drumstick >> to provide a cmake file, which is always more convenient. > > Hi, > > I've changed CMakeLists.txt to find out drumstick libs using > pkg_check_modules, > which is the way other drumstick clients (like KMetronome, KMidimon) > actually do. > I confirm that works fine at least in Arch, KUbuntu, openSUSE, and Fedora > (other > distros should package drumstick's pkg-config files similarly). > > The three weeks period (two weeks review + one week after completion > of requested changes) > ends tomorrow. I plan to move it to KDE edu by the end of this week, > so that further suggestions > are quite welcome :) > > Also, could someone clarify the questions I raised before? (copied below) > > * Regarding Minuet versioning itself: should I use the automatic version > numbering from release script or should I start from a 1.0.0 release? > * Also, where are those release scripts stored (some repository)?
That seems to be the release-tools.git repository. Following the version numbering of KDE Applications would be nice for consistency but it may not reflect the fact Minuet is yet in its early days. Suggestions? Sandro > > Cheers, > Sandro > >> >> Aleix
