Getting ecm files from the ECM package

[Michael Pyne]

> On 11/01/2013 10:46 AM, Alexander Neundorf wrote:
> > [1] Why not merge that into CMake ? For quicker releases, and even easier
> > contributing. Also Bill once said that in hindsight he would have prefered
> > if
> > cmake would not ship any find-modules itself at all. So one could imagine
> > that cmake would come without any find-modules in the future, and all
> > find-modules would come from a separate package, e.g. ECM.
> > This would make cmake the core tool, and ECM its "standard library"
> 
> I agree that a separation of CMake and the find_modules make sense. But.
> Then it is time to think of a way to integrate cmake with the separate
> source of find_modules. Algorithmically, it would look like
> 
> PROJECT(MyApplication)
> FIND_MODULES_REPOSITORY("http://ecm.kde.org")
> FIND_PACKAGES(KF5 REQUIRED...)
> 
> and so forth. That would be a real breakthrough. It is related to the
> approach taken by Maven and others. All it takes is a built-in way for
> CMake to download the find_modules into a cache location and update them
> when needed, or on request.

I don't really feel comfortable with the idea of the build process hitting the 
Internet to download more code (CMake or otherwise) to execute as part of the 
build. Yes, this does mean I dislike the Maven concept too. :)

It's hard to audit, hard to keep secure, and it shouldn't really be necessary 
as it's rare that you'd be just running CMake by yourself to build an 
individual git repo with all the splitting we've done.

If you're using a build script that script should already be taking care of 
updating ECM just like any other build dependency. For example ECM is one of 
the first modules kdesrc-build builds in the default config, and likewise for 
the kf5 kdesrc-buildrc that is being maintained.

I see what you're getting at though. It would be nice if CMake could 
automatically improve it's ability to find libraries and modules. But that 
shouldn't happen at build time, it's hard to version the code that ends up 
being used and it's also going to be very hard for our users who build from 
tarballs (not to mention our downstreams who are quite worried about security, 
for obvious reasons nowadays).

> This would also make a lot of things a lot easier. For example, nobody would
> need to separately install ECM, and updates to our ECM packages can be
> delivered globally by commits to that repo.

Well, separate installation isn't that hard in the context of needing 17 
different git repos just to do anything as it stands now. There's admittedly 
some hyperbole there, but not much! ;)

Likewise, updating a central repo can work whether CMake downloads ECM or 
whether the existing build script or packaging script does it. It's still 
pulling from the same repo in the end.

Please let me know if kdesrc-build is unsuitable as it stands now and I can 
try to fix it (or point to what's broken so others can). I'd hate for us to 
spend a lot of time implementing a new CMake feature to use instead of an 
existing 95% solution. Either way, even if kdesrc-build doesn't work, Michael 
Jansen's excellent build-tool is out there as well.

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20131101/76dbc58c/attachment.sig>