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

List:       kde-buildsystem
Subject:    Re: Buildsystem TODO list
From:       Michael Jansen <kde () michael-jansen ! biz>
Date:       2011-08-23 18:08:40
Message-ID: 1807375.xLVrnKKrHr () gambit
[Download RAW message or body]

On Tuesday, August 23, 2011 07:35:41 PM Alexander Neundorf wrote:
> On Tuesday 23 August 2011, Raphael Kubo da Costa wrote:
> > "Yury G.  Kudryashov" <urkud.urkud@gmail.com> writes:
> > > Raphael Kubo da Costa wrote:
> > > 
> > > As far as I understand, the proposed scenario for projects with
> > > cmake-based
> > > 
> > > buildsystem is:
> > >  * the project itself installs ProjectNameConfig.cmake;
> > >  * ecm (or cmake) distribute a short FindProject.cmake that calls
> > > 
> > > find_package(ProjectName ... NO_MODULE ...)
> > > 
> > > One of the examples is kdepimlibs.
> > 
> > This could work, but is the second part really necessary? If only
> > ProjectNameConfig.cmake exists and the application using it does not
> > have its own FindProjectName.cmake, when it calls
> > find_package(ProjectName) CMake would find ProjectNameConfig.cmake
> > anyway.
> 
> A nice feature of having a Find-file, even if it only does
> find_package(NO_MODULE), is that it can contain documentation about provided
> variables and macros.



> It can also add additional search paths, 

NO WAY ... Everything else i wholeheartily agree. But this? ... NO WAY

Please do not mess with my carefully setup build environment by injecting 
PATHES into it i have NO WAY to remove short of patching the module.

Mike

_______________________________________________
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
[prev in list] [next in list] [prev in thread] [next in thread]