On Friday 01 November 2013 15:46:30 Nicolás Alvarez wrote:
> 2013/11/1 Kevin Ottens <er...@kde.org>:
> > Hello,
> >
> > On Friday 01 November 2013 11:23:14 Mirko Boehm wrote:
> >> 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.
> >
> > My position indeed. I would agree at a "tier 0" if it didn't make it
> > miserable for third parties wanting to use a tier 1 library in the sense
> > of "oh by the way you also need that, and that, and that thing no one
> > else use".>
> >> 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.
> >
> > Yes, that's definitely something we've been missing for a long time
> > compared to the java crowd who massively use Maven. It is an *excellent*
> > feature, and would solve this kind of headaches we have with the build
> > system.
>
> I don't know how to even begin arguing against this, because if you
> don't see how wrong it is to download stuff during compilation, I
> don't know what arguments would help.
>
> I actively avoid any build system that automatically downloads
> dependencies. In fact, I avoid any tool that automatically downloads
> and installs software except for my distro's package manager and
> kdesrc-build. That means no easy_install, pip, rubygems, npm, maven,
> or whatever NIH package manager the $language community invented now.
+1
builds should NEVER download anything
If it is needed it should be an EXPLICIT dependency, which I can fetch
beforehand
>
> Maven is a disgusting monstrosity used by the Java crowd where
> backwards compatibility rarely exists, and the approach to make things
> not break is to make packages depend on exact versions of dependencies
> and download them automatically from who-knows-where. And then the
> same craziness gets copied or reinvented for other languages too.
>
> "You don’t want a build tool which automatically downloads unresolved
> dependencies before cleaning out your build output directories. You
> don’t want a build tool which automatically downloads unresolved
> dependencies, PERIOD! Automatically downloading unresolved
> dependencies makes your build process nondeterministic!" --
> http://kent.spillner.org/blog/work/2009/11/14/java-build-tools.html
>
> I'm also surprised at "Almost everybody has internet access for build
> machines". Is there *any* Linux distro where that's the case??
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
