Portfiles with fetch.type git ... can one add arguments to git?

[Ian Wadham]

Hi René,

On 17/08/2014, at 5:59 PM, René J.V. Bertin wrote:
> On Sunday August 17 2014 08:10:58 Ian Wadham wrote:
> Just for the anecdote: cloning kdevelop and kdevplatform with --depth=1 reduces the footprint by about a factor 10 …

:-) KDevelop has a huge history. I can remember when one of its many
versions was codenamed Gideon.

>> Have you considered using KDE's "kdersrc-build" scripts with the additions
>> I have developed (and use) for MacPorts and OS X?  With them, you can
>> have "bleeding edge" versions of whatever KDE software you wish and
>> use stable versions of Qt, etc. taken from MacPorts.  See [1].
> 
> Heh, I have [considered] now ;)

Great!

> Pity one cannot have Qt4 and Qt5 together in MacPorts (right?)

I don't know why not.  In Linux and Windows, the libraries and utilities for Qt4,
KDE 4, Qt5, KDE Frameworks and KF 5 are going to have to co-exist for a
while, starting in earnest in December, when the first "mixed" batch of KDE
apps is released … some ported to Frameworks and many not …

>> kde4-runtime sources, on local repos. and hardly ever need to do more
>> than "edit", "make Install" and maybe the odd "kbuildsycoca4" for luck.
> 
> You know you can also do `make install/fast`

Thanks for the tip, I was unaware of that one.  Seems it's a CMake feature.

> and you don't have to build
> the full package when you change something in, say, kdelibs/kdeui ?
> That's what I've been doing while hacking the kwallet subsystem.

No, I usually just rebuild kdeui, but it seems there are glitches if I go
down a level.

> Can you resume what the future is for kdelibs4? Is it going to be kept
> around in KF 5 so that improvements we made will carry over to KF 5?
> Or are we supposed to do everything we did for kdelibs4 again for KF 5?

I wish I knew --- or could even find definitive documents of what the
objectives, design and development plans of Frameworks really are.

But it seems that it is not such a radical re-write/re-design as the KDE3/4
transition was.  People in KDE Games at least are finding it fairly easy
to port games to Frameworks.  The CMakeLists.txt has to be radically
re-written because of the different grouping of KDE library classes
into libraries and the superseding of some classes by Qt 5 classes.

The surviving KDE classes seem not to have changed much in their API.

So I think most of the patches MacPorts develops for KDE 4 will be forward
ported into Frameworks or will at least inspire KDE developers as to how
to do things "properly" for Apple OS X in the future.

Obviously, if we were to develop a decent patch for KFileDialog, which should
always yield OS X dialogs, it would have a limited life (I estimate 2 to 3 years),
because KDE apps will eventually supersede KFileDialog with QFileDialog.

So it could still be worth writing patches for KDE 4 even if they do not get used
in Frameworks.  At least they will be useful for a while in MacPorts.

For a rough guide of the extent of changes see [1].

Cheers, Ian W.

[1] https://community.kde.org/Frameworks/Porting_Notes