[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-mac
Subject:    Re: [KDE/Mac] subport and keyword questions/suggestions
From:       <MK-MacPorts () techno ! ms>
Date:       2015-02-15 18:33:01
Message-ID: 185D7893-83A3-4359-9762-62C988F7BA06 () techno ! ms
[Download RAW message or body]

Hi Ren=E9,

only now I saw your post and I also wonder what the best approach
would be...

> - Do the build slaves build the default variants of subparts?

Well, actually, I don=92t know for sure. I=92d say no, but I guess
this needs to be tested, if no-one can tell us. ;-)


> I *think* that the mechanism that's currently in place to let client port=
s accept qt5-mac-devel instead of qt5-mac should also let them accept qt5-m=
ac[-devel]-kde instead of qt5-mac, but that remains to be confirmed.

Which mechanism is used there? I guess it won=92t be as simple
anymore as using depends_lib: =

---
   depends_lib-append path:lib/libaqbanking.dylib:aqbanking5
---
since now the various qt5-mac-* installs will all have very
different paths...


> @kde-mac: what do you think, should I prepare a qt5-mac-kde subport? I'd =
prefer to lay the foundations for that now if we think that there's enough =
chance it'll become necessary, rather than have to come back to my Portfile=
 code at a future time (and potentially disrupt a lot more Qt5 client ports=
 than I currently have).

This might be a good idea, Ren=E9.

Having said that I am unsure whether a port, a subport or a
variant is the fail-safest approach.

I wish we had some wiki pages explaining what is the best
choice for portfile development in this respect. Probably we
have such a page even somewhere hidden=85 :)

Greets,
Marko
_______________________________________________
kde-mac@kde.org
List Information: https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac Information: http://community.kde.org/Mac
[prev in list] [next in list] [prev in thread] [next in thread]