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

Matthew Hanna (BLOOMBERG/ 731 LEX) mhanna21 at bloomberg.net
Thu Apr 20 17:16:55 EDT 2017


After checking several approaches, it looks as though the number of
edges in the inference algorithm is the bottleneck, regardless of the
number of cycles inferred.  In our particular case, the number of
external dependencies far outnumbers the known, internal libraries.
Also, since we are using pkg-config, the external dependencies are
not well ordered, so inferences involving two external deps are bound
to be misleading.  Given that, the approach we are considering is to
avoid adding the external to external edges, but still leave all edges
that contain at least one known library.  The desired effect is
sketched out in the following commit:

https://gitlab.kitware.com/mhanna21/cmake/commit/2c7d2e33b6218e58f88957fb793ce0a781ec76aa

Thanks,
Matthew

From: mhanna21 at bloomberg.net At: 04/11/17 12:05:50
To: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Proposal to disable link depends inference.

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.king at kitware.com At: 04/11/17 11:16:27
To: cmake-developers at 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  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170420/fb7c0f2c/attachment-0001.html>


More information about the cmake-developers mailing list