Re: [cmake-developers] Feature suggestion: auto-create missing files

[Alexander Neundorf]

On 2017 M04 11, Tue 11:52:52 CEST Brad King wrote:
> On 04/11/2017 11:41 AM, Petr Kmoch wrote:
> > Currently, adding a new source file to a CMake-controlled project
> > means doing two things: creating the file on disk, and adding it
> > to the relevant CMakeList add_library() or add_executable() call.
> 
> I view this as a matching pair with an implicit sanity check.
> 
> > switch from current behaviour of "error out if source file is not found"
> > to "create empty source file if it's not found."
> 
> So a typo in the `CMakeLists.txt` file leads to silent creation of a
> source file instead of an error message?
> 
> That said, I can see how the proposed feature might be useful when
> iteratively developing in an IDE.  Add the file to `CMakeLists.txt`,
> reconfigure, and open the new (now existing) file to edit in the IDE.
> 
> > Is this something that would be acceptable into CMake? Any comments?
> 
> I'd like to hear more opinions from others before considering it
> upstream.  It feels like a pretty personal workflow right now, and
> can be implemented in CMake code already (perhaps with the `SOURCES`
> target property to avoid separate lists).

personally I'm not convinced.
Technically it would violate the "the source dir is read-only" rule.
A typo would generate files. With multiple build dirs the behaviour will be 
slightly different in the two dirs.
...not very strong arguments, but OTOH touching the file manually is also not 
too complicated.

Alex

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Fwd: Feature suggestion: auto-create missing files

[Charles Huet]

I personally really like the approach taken by FastBuild where you can
specify a folder in which the source resides, and it will take care of
compiling all the files within.

A checksum to verify if there are new files, and if not no need to
reconfigure.

This could pretty much be used with globing as well, making it a more
useful feature.

Also, I really appreciate the fact that you can't forget an old source file
by mistake (removed in the CMakeLists.txt but not on disk) this way.

Just my 2 cents.

On Tue, Apr 11, 2017, 19:15 Alex Turbov  wrote:

>
>
> Hi,
>
> here is my 5 cents...
>
> On Tue, Apr 11, 2017 at 10:52 PM, Brad King  wrote:
>
> On 04/11/2017 11:41 AM, Petr Kmoch wrote:
> > Currently, adding a new source file to a CMake-controlled project
> > means doing two things: creating the file on disk, and adding it
> > to the relevant CMakeList add_library() or add_executable() call.
>
> I view this as a matching pair with an implicit sanity check.
>
> +1
>
>
> > switch from current behaviour of "error out if source file is not found"
> > to "create empty source file if it's not found."
>
> So a typo in the `CMakeLists.txt` file leads to silent creation of a
> source file instead of an error message?
>
> +1
>
> doesn't looks like a good idea... also if someone (re)moved/renamed a file
> intentionally and forget to update CMakeLists.txt (or just rerun `make`
> which executes `cmake`)
>
>
> That said, I can see how the proposed feature might be useful when
> iteratively developing in an IDE.  Add the file to `CMakeLists.txt`,
> reconfigure, and open the new (now existing) file to edit in the IDE.
>
>
> my personal practice completely the opposite:
> in my CMakeLists I have a custom target to generate a source file from the
> project specific template, so I just use CLI to generate a new file like:
>
> $ make new-class name=BlahBlah ns=Vendor::Project subdir=some/dir
>
> and then go to corresponding CMakeLists.txt and add the generated
> source(s) to a target
> and thanks to `cmake` missed files are reported at configuration time
>
>
> > Is this something that would be acceptable into CMake? Any comments?
>
> I'd like to hear more opinions from others before considering it
> upstream.  It feels like a pretty personal workflow right now, and
> can be implemented in CMake code already (perhaps with the `SOURCES`
> target property to avoid separate lists).
>
> If this were to be done I'd first like to see a policy introduced to
> get rid of the magic extension guessing we do now.  Without knowing
> the full file name with confidence we wouldn't be able to create it.
>
> -Brad
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Mirror CMake release files on GitHub?

[Brad King]

On 04/10/2017 05:56 PM, Rolf Eike Beer wrote:
>> Thanks.  I'll take a look at that when I get a chance.
> 
> Now would be a good time ;)

I wish it were but I can't make this a priority now.

Our admins did fix a network performance problem that led
to the OP's reported trouble so the speed from cmake.org
should be much better than it was.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] External projects & library dependencies

[Wouter Klouwen]

Hi Brad,

thanks for taking the time to reply.

On 11/04/17 18:00, Brad King wrote:

On 04/11/2017 12:33 PM, Wouter Klouwen wrote:

So in order to create a mega project I want to put all of the third
party packages into the build system using ExternalProject_Add.
This function does provide for targets in terms of build dependencies,
but this isn't quite enough. I need these packages to convey information
in the same way as was done through pkg-config files and provide
COMPILE_OPTIONS, INCLUDE_DIRECTORIES and LINK_LIBRARIES.

All of this information is present once the ExternalProject is built as
it would be possible to invoke pkg-config afterwards. This is of course
too late for CMake to resolve this information at configure/build rule
creation time.

Is there a better way of solving this other than effectively duplicating
the information in the pkg-config files so that CMake can read it at
generation time?


Make your outer project a "superbuild" that does not compile anything
itself but instead just uses ExternalProject_Add to build everything
else in dependency order.  That way each project won't configure until
all its dependencies are built.


Unfortunately this isn't really an option for us. There's a non trivial
amount of third party packages that take a non trivial amount of time to
compile.
Waiting for all of these to compile while not yet starting on our own
projects would create a very long critical path before the build could
fan out for all targets. This would have a detrimental impact on our
build performance.

I appreciate it's not a usual problem as this is for an embedded
platform where we have to cross build everything from scratch.

Thanks,
W


This transmission contains information that may be confidential and contain 
personal views which are not necessarily those of YouView TV Ltd. YouView TV 
Ltd (Co No:7308805) is a limited liability company registered in England and 
Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames 
Street, London, EC3R 6YT. For details see our web site at http://www.youview.com
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Fwd: Feature suggestion: auto-create missing files

[Alex Turbov]

Hi,

here is my 5 cents...

On Tue, Apr 11, 2017 at 10:52 PM, Brad King  wrote:

> On 04/11/2017 11:41 AM, Petr Kmoch wrote:
> > Currently, adding a new source file to a CMake-controlled project
> > means doing two things: creating the file on disk, and adding it
> > to the relevant CMakeList add_library() or add_executable() call.
>
> I view this as a matching pair with an implicit sanity check.
>
+1

>
> > switch from current behaviour of "error out if source file is not found"
> > to "create empty source file if it's not found."
>
> So a typo in the `CMakeLists.txt` file leads to silent creation of a
> source file instead of an error message?
>
+1

doesn't looks like a good idea... also if someone (re)moved/renamed a file
intentionally and forget to update CMakeLists.txt (or just rerun `make`
which executes `cmake`)


> That said, I can see how the proposed feature might be useful when
> iteratively developing in an IDE.  Add the file to `CMakeLists.txt`,
> reconfigure, and open the new (now existing) file to edit in the IDE.
>

my personal practice completely the opposite:
in my CMakeLists I have a custom target to generate a source file from the
project specific template, so I just use CLI to generate a new file like:

$ make new-class name=BlahBlah ns=Vendor::Project subdir=some/dir

and then go to corresponding CMakeLists.txt and add the generated source(s)
to a target
and thanks to `cmake` missed files are reported at configuration time


> > Is this something that would be acceptable into CMake? Any comments?
>
> I'd like to hear more opinions from others before considering it
> upstream.  It feels like a pretty personal workflow right now, and
> can be implemented in CMake code already (perhaps with the `SOURCES`
> target property to avoid separate lists).
>
> If this were to be done I'd first like to see a policy introduced to
> get rid of the magic extension guessing we do now.  Without knowing
> the full file name with confidence we wouldn't be able to create it.
>
> -Brad
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] External projects & library dependencies

[Brad King]

On 04/11/2017 12:33 PM, Wouter Klouwen wrote:
> So in order to create a mega project I want to put all of the third
> party packages into the build system using ExternalProject_Add.
> This function does provide for targets in terms of build dependencies,
> but this isn't quite enough. I need these packages to convey information
> in the same way as was done through pkg-config files and provide
> COMPILE_OPTIONS, INCLUDE_DIRECTORIES and LINK_LIBRARIES.
> 
> All of this information is present once the ExternalProject is built as
> it would be possible to invoke pkg-config afterwards. This is of course
> too late for CMake to resolve this information at configure/build rule
> creation time.
> 
> Is there a better way of solving this other than effectively duplicating
> the information in the pkg-config files so that CMake can read it at
> generation time?

Make your outer project a "superbuild" that does not compile anything
itself but instead just uses ExternalProject_Add to build everything
else in dependency order.  That way each project won't configure until
all its dependencies are built.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Feature suggestion: auto-create missing files

[Ben Boeckel]

On Tue, Apr 11, 2017 at 11:52:52 -0400, Brad King wrote:
> If this were to be done I'd first like to see a policy introduced to
> get rid of the magic extension guessing we do now.  Without knowing
> the full file name with confidence we wouldn't be able to create it.

This is already an issue here:

https://gitlab.kitware.com/cmake/cmake/issues/15208

I have a branch which needs lots of work to be rebased properly; I can
dig it up if anyone is interested in taking it over before I get to it.

--Ben
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] External projects & library dependencies

[Wouter Klouwen]

Hello all,

I've been converting a large build system to use CMake. At the moment it
consists of a custom build system that builds 250+ projects plus a
series of third party open source packages, that each have their own
build system. After some effort I've been able to convert all of our own
projects to use CMake.

This brings us to the next challenge as I'm now in the position where I
want to create one CMake, so that it can take over from our own build
system.
There's a major thing I can't find a good solution for yet. At the
moment each project is built individually and in order. As there's
multiple levels of build systems involved. So include and link flags
between these projects can be transferred through either CMake packages
or FindPkgConfig, for our own CMake projects and the third party
packages respectively. Both of these methods provide for interface
libraries that can be neatly depended on.

So in order to create a mega project I want to put all of the third
party packages into the build system using ExternalProject_Add.
This function does provide for targets in terms of build dependencies,
but this isn't quite enough. I need these packages to convey information
in the same way as was done through pkg-config files and provide
COMPILE_OPTIONS, INCLUDE_DIRECTORIES and LINK_LIBRARIES.

All of this information is present once the ExternalProject is built as
it would be possible to invoke pkg-config afterwards. This is of course
too late for CMake to resolve this information at configure/build rule
creation time.

Is there a better way of solving this other than effectively duplicating
the information in the pkg-config files so that CMake can read it at
generation time?

Thanks in advance,
 W
This transmission contains information that may be confidential and contain 
personal views which are not necessarily those of YouView TV Ltd. YouView TV 
Ltd (Co No:7308805) is a limited liability company registered in England and 
Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames 
Street, London, EC3R 6YT. For details see our web site at http://www.youview.com
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Feature suggestion: auto-create missing files

[Petr Kmoch]

Thanks for the quick response, Brad.

On 11 April 2017 at 17:52, Brad King  wrote:

> On 04/11/2017 11:41 AM, Petr Kmoch wrote:
> > Currently, adding a new source file to a CMake-controlled project
> > means doing two things: creating the file on disk, and adding it
> > to the relevant CMakeList add_library() or add_executable() call.
>
> I view this as a matching pair with an implicit sanity check.
>

I sometimes have very deep directory hierarchies (files are 3+ directory
levels below the CMakeLists.txt), with interface header, implementation
header, and implementation source in three different paths down that
hierarchy. Adding one class means adding three very similar lines of CMake
code, and then having to navigate three separate directory paths for adding
the files.


>
> > switch from current behaviour of "error out if source file is not found"
> > to "create empty source file if it's not found."
>
> So a typo in the `CMakeLists.txt` file leads to silent creation of a
> source file instead of an error message?
>

That's why I would make it strictly opt-in. We could even get rid of the
initialisation variable and keep it under full control of the project.


>
> That said, I can see how the proposed feature might be useful when
> iteratively developing in an IDE.  Add the file to `CMakeLists.txt`,
> reconfigure, and open the new (now existing) file to edit in the IDE.
>

Yes, I'm coming from an IDE background (VS, to be precise). It would be
quite helpful there. I've bounced the idea with other people in my team,
and they agreed it would be useful.


>
> > Is this something that would be acceptable into CMake? Any comments?
>
> I'd like to hear more opinions from others before considering it
> upstream.  It feels like a pretty personal workflow right now, and
> can be implemented in CMake code already (perhaps with the `SOURCES`
> target property to avoid separate lists).
>
> If this were to be done I'd first like to see a policy introduced to
> get rid of the magic extension guessing we do now.  Without knowing
> the full file name with confidence we wouldn't be able to create it.
>

I'm perfectly fine waiting for broader comments. As to extension guessing,
right now the creation happens after that step in my prototype code, and
simply uses the name verbatim as supplied. I'm perfectly willing to create
such a guess-disabling policy, though. I've never used the guessing
functionality anyway.

Petr
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Proposal to disable link depends inference.

[Matthew Hanna (BLOOMBERG/ 731 LEX)]

Yes, disabling the 'magic guessing' is the primary goal.  I just wanted
to test the waters before embarking on a patch.  Will continue the
conversation once I have a patch ready that solves our problem.

Thanks,
Matthew
From: brad.k...@kitware.com At: 04/11/17 11:16:27
To: cmake-developers@cmake.org
Subject: Re: [cmake-developers] Proposal to disable link depends inference.

On 04/11/2017 09:34 AM, Matthew Hanna (BLOOMBERG/ 731 LEX) wrote:
> The inference logic in cmComputeLinkDepends.cxx is both inefficient and
> superfluous for our specific use case. I am proposing a global setting that
> would disable the link computation entirely for those that wish to take full
> responsibility of the ordering of dependencies.

IIUC you're not talking about disabling the entire dependency analysis
but instead just turning off the magic guessing of implicit dependencies
based on observed order.  Correct?

Before we bikeshed the name and form of the setting, can you post a patch
that just removes the logic outright so we can see exactly what you mean?

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Feature suggestion: auto-create missing files

[Brad King]

On 04/11/2017 11:41 AM, Petr Kmoch wrote:
> Currently, adding a new source file to a CMake-controlled project
> means doing two things: creating the file on disk, and adding it
> to the relevant CMakeList add_library() or add_executable() call.

I view this as a matching pair with an implicit sanity check.

> switch from current behaviour of "error out if source file is not found"
> to "create empty source file if it's not found."

So a typo in the `CMakeLists.txt` file leads to silent creation of a
source file instead of an error message?

That said, I can see how the proposed feature might be useful when
iteratively developing in an IDE.  Add the file to `CMakeLists.txt`,
reconfigure, and open the new (now existing) file to edit in the IDE.

> Is this something that would be acceptable into CMake? Any comments?

I'd like to hear more opinions from others before considering it
upstream.  It feels like a pretty personal workflow right now, and
can be implemented in CMake code already (perhaps with the `SOURCES`
target property to avoid separate lists).

If this were to be done I'd first like to see a policy introduced to
get rid of the magic extension guessing we do now.  Without knowing
the full file name with confidence we wouldn't be able to create it.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Feature suggestion: auto-create missing files

[Petr Kmoch]

Hi all,

I'd like to implement a feature for CMake which I miss there, and I'd like
to get approval for the idea & design before proceeding.

Currently, adding a new source file to a CMake-controlled project means
doing two things: creating the file on disk, and adding it to the relevant
CMakeList add_library() or add_executable() call. To me, this feels like
one operation too many. As a result, nearly all of my personal projects
using CMake end up with some sort of wrapper/pre-call which processes file
lists and creates any missing files before the list is passed to the
add_*() call.

I'd like this behaviour to become an option in CMake itself: allow the user
to switch from current behaviour of "error out if source file is not found"
to "create empty source file if it's not found." I've prototyped the
creation itself and it works, but I'd like to discuss the interface for
enabling this functionality. I was considering an inherited boolean
property on individual source file level, plus a variable which would
pre-initialise the property if set. This way, projects could control it on
the finest scope possible (or on broader scopes, since the prorepty would
recurse to directory & global level), while still providing a simple way to
set it centrally.

As far as naming is concerned, I was considering CREATE_SOURCES_IF_MISSING
for the property, and CMAKE_CREATE_SOURCES_IF_MISSING for the variable.

Is this something that would be acceptable into CMake? Any comments?

Thanks.

Petr
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Proposal to disable link depends inference.

[Brad King]

On 04/11/2017 09:34 AM, Matthew Hanna (BLOOMBERG/ 731 LEX) wrote:
> The inference logic in cmComputeLinkDepends.cxx is both inefficient and
> superfluous for our specific use case. I am proposing a global setting that
> would disable the link computation entirely for those that wish to take full
> responsibility of the ordering of dependencies.

IIUC you're not talking about disabling the entire dependency analysis
but instead just turning off the magic guessing of implicit dependencies
based on observed order.  Correct?

Before we bikeshed the name and form of the setting, can you post a patch
that just removes the logic outright so we can see exactly what you mean?

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Proposal to disable link depends inference.

[Matthew Hanna (BLOOMBERG/ 731 LEX)]

Hi,

The inference logic in cmComputeLinkDepends.cxx is both inefficient and
superfluous for our specific use case.  I am proposing a global setting that
would disable the link computation entirely for those that wish to take full
responsibility of the ordering of dependencies.

We are currently using the FindPkgConfig module for generating link lines.
Following the pkg-config guidance, dependencies on system libraries are noted
in the "Libs" section of the pkg-config file as opposed to the "Requires"
section.  This means that common system libraries such as rt are repeated on
the link line.  Unfortunately, this appears to be causing the inference in
cmComputeLinkDepends.cxx to construct highly connected graphs resulting in
delays of several minutes.

For example, consider package X that depends on Y, where both depend on rt.
Since rt is a system library, pkg-config generates -lX -lrt -lY -lrt.  Now
there appears to be a cyclic dependency between rt and Y that the link logic
will attempt to grapple with.  The same problem can also occur even when
pkg-config files only contain a single unique library.  This is because the
output is not well ordered, so two targets might have the order of independent
libraries reversed, and I believe the inference is done globally, so a cycle
inference is possible.  As the number of dependent libraries increases, the
number of edges in the inferred graph explodes.

We have attempted to optimize the algorithm by removing redundant edges, but
this has only had marginal effects.  Assuming that we wish to take
responsibility for avoiding cycles, I would like a mechanism to disable the
inference logic.  One approach would be to extend the semantics of
LINK_INTERFACE_MULTIPLICITY such that setting it to 1 would disable inference
and leave link lines untouched.  However, since this is largely a property of
the library set as opposed to a single target, I would prefer a way to disable
inference at a global level, such as in a custom toolchain file.

Matthew-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers