Re: [cmake-developers] Response files with IAR compiler on windows

[Andreas Weis]

Thanks, Daniel. I opened a pull request for the issue.

Best regards,
Andreas

On 5/22/2017 9:10 AM, Daniel Pfeifer wrote:

Hi Andreas,

could you please make a pull request on Gitlab?
See here for the preferred way for contributions: 
https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst


Cheers, Daniel

On Sun, May 21, 2017 at 11:52 PM, Andreas Weis 
> wrote:


Hi,

We are using the IAR toolchain for cross-compiling parts of our
builds and encountered a problem when we recently enabled response
files for our Windows builds. It seems that the syntax used for the
response file flags on the IAR compilers is wrong, we needed to
insert a space after the '-f' to make it work.

I attached a patch that fixes the problem in our environment.

We are building with the 'Unix Makefiles' generator from a Cygwin
shell in Windows. Can someone confirm that this is a proper fix for
our issues and whether it would make sense to have the patch merged
into the CMake trunk?

Thanks & best regards,
Andreas

--

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] Compile targets affected by changeset

[Florent Castelli]

Depending on your setup and the amount of build machines, you may have 
even better results with sccache from Mozilla. It's a new implementation 
similar to ccache with an optional distributed cache in S3 or Redis.


The downside is if you have long running tests in the list, it won't 
help you much (unless you have a way to checksum the test programs and 
skip them maybe?). But still, it's always a good thing to rerun them as 
you may have some unstable tests and more runs means more confidence.


/Florent

On 22/05/2017 23:06, Craig Scott wrote:
I highly recommend Florent's suggestion. We use ccache on our CI 
system and for local development. We've stopped worrying about how 
long builds take now, since only files that are changed or that rely 
on things that changed contribute any meaningful amount to the build 
time. It also works for Make, Ninja and Xcode, so it's more flexible 
than relying on some feature of Make and it is also pretty easy to set 
up. You can set it up system wide, or you can take the approach 
discussed in this article 
 for systems 
where you don't have access to set up ccache globally.



On Tue, May 23, 2017 at 4:54 AM, Florent Castelli 
> wrote:




On 22 May 2017, at 20:07, Robert Patterson via cmake-developers
>
wrote:

We understand that CMake and make already can rebuild targets
which depend on changed files, and this behavior works exactly as
expected for us. Our issue is not that make is rebuilding targets
that it shouldn't. We would like this 'compile targets which
changed' behavior to work from a clean state, not just for
subsequent rebuilds. That is, from the first time cmake / make is
invoked, only the targets that depend on the given set of files
will be built, and no more.

When a developer submits a changeset to our continuous
integration tool, a fresh copy of the repository is checked out
by the worker at the commit of the changeset. We can access the
set of changed files from the commit data. Currently, cmake and
make correctly identify that the system is in a clean state and
that everything should be built if the current top-level target
is specified. This is the point where we would like our behavior
to differ. We want the rebuild changed targets behavior as if
everything were already built, but from this clean state.

Once we have determined the targets to build, we could simply
specify these targets as goals to make in the command line, but
we are hampered by the following limitation of make.

We are using GNU make 3.82. Invoking 'make -j target1 target2
target3' on the command line specifies the targets as goals to
make. If several goals are specified, 'make' processes each of
them in turn, in the order you name them.
https://www.gnu.org/software/make/manual/html_node/Goals.html


Ninja does not currently work for our project.


It would be interesting to fix Ninja for your project then. Do you
know what isn’t currently working?
Also, Ninja has some APIs to expose all the dependency graph,
which you could probably query somehow to find out which target
you need to rebuild.

Another possibility, albeit a bit different, could be to use a
compilation cache to just rebuild everything but much faster, to
the point that it might not be relevant anymore.

/Florent




On May 19, 2017, at 2:32 AM, Simon Richter
> wrote:

Hi,

On 18.05.2017 23:48, Robert Patterson via cmake-developers wrote:


My company has a large, predominately C++ codebase, with
hundreds of
targets, both for product and unit tests.  In an effort to
improve the
compile and test time for developers, which utilizes a continuous
integration infrastructure, it is desirable to compile only the
targets
that are affected by developer's change sets.


Erm, it should already work this way. If Make rebuilds a target
that it
shouldn't, the first step would be investigating why it thinks the
target needs to be rebuilt.

Dependency tracking is one of the oldest problems, and cmake
should use
an appropriate solution for the actual build system you use. The
approach used for Make is a bit more conservative than you would
require
for GNU Make, but should nevertheless still work.

http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/


is a good primer on dependency list generation with Make -- CMake
generates rules that are similar to these.


'make' has a 

Re: [cmake-developers] Compile targets affected by changeset

[Craig Scott]

I highly recommend Florent's suggestion. We use ccache on our CI system and
for local development. We've stopped worrying about how long builds take
now, since only files that are changed or that rely on things that changed
contribute any meaningful amount to the build time. It also works for Make,
Ninja and Xcode, so it's more flexible than relying on some feature of Make
and it is also pretty easy to set up. You can set it up system wide, or you
can take the approach discussed in this article
 for systems where
you don't have access to set up ccache globally.


On Tue, May 23, 2017 at 4:54 AM, Florent Castelli <
florent.caste...@gmail.com> wrote:

>
> On 22 May 2017, at 20:07, Robert Patterson via cmake-developers <
> cmake-developers@cmake.org> wrote:
>
> We understand that CMake and make already can rebuild targets which depend
> on changed files, and this behavior works exactly as expected for us. Our
> issue is not that make is rebuilding targets that it shouldn't. We would
> like this 'compile targets which changed' behavior to work from a clean
> state, not just for subsequent rebuilds. That is, from the first time cmake
> / make is invoked, only the targets that depend on the given set of files
> will be built, and no more.
>
> When a developer submits a changeset to our continuous integration tool, a
> fresh copy of the repository is checked out by the worker at the commit of
> the changeset. We can access the set of changed files from the commit data.
> Currently, cmake and make correctly identify that the system is in a clean
> state and that everything should be built if the current top-level target
> is specified. This is the point where we would like our behavior to differ.
> We want the rebuild changed targets behavior as if everything were already
> built, but from this clean state.
>
> Once we have determined the targets to build, we could simply specify
> these targets as goals to make in the command line, but we are hampered by
> the following limitation of make.
>
> We are using GNU make 3.82. Invoking 'make -j target1 target2 target3' on
> the command line specifies the targets as goals to make. If several goals
> are specified, 'make' processes each of them in turn, in the order you name
> them. https://www.gnu.org/software/make/manual/html_node/Goals.html
>
> Ninja does not currently work for our project.
>
>
> It would be interesting to fix Ninja for your project then. Do you know
> what isn’t currently working?
> Also, Ninja has some APIs to expose all the dependency graph, which you
> could probably query somehow to find out which target you need to rebuild.
>
> Another possibility, albeit a bit different, could be to use a compilation
> cache to just rebuild everything but much faster, to the point that it
> might not be relevant anymore.
>
> /Florent
>
>
> On May 19, 2017, at 2:32 AM, Simon Richter 
> wrote:
>
> Hi,
>
> On 18.05.2017 23:48, Robert Patterson via cmake-developers wrote:
>
> My company has a large, predominately C++ codebase, with hundreds of
> targets, both for product and unit tests.  In an effort to improve the
> compile and test time for developers, which utilizes a continuous
> integration infrastructure, it is desirable to compile only the targets
> that are affected by developer's change sets.
>
>
> Erm, it should already work this way. If Make rebuilds a target that it
> shouldn't, the first step would be investigating why it thinks the
> target needs to be rebuilt.
>
> Dependency tracking is one of the oldest problems, and cmake should use
> an appropriate solution for the actual build system you use. The
> approach used for Make is a bit more conservative than you would require
> for GNU Make, but should nevertheless still work.
>
> http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/
>
> is a good primer on dependency list generation with Make -- CMake
> generates rules that are similar to these.
>
> 'make' has a limitation where if 'make target1 target2 target3' is
> invoked, target1, target2, and target3 are built serially, not in
> parallel.
>
>
> Which version of make are you using?
>
>   Simon
>
> --
>
> 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:
> 

Re: [cmake-developers] Problems with external language support when there is a blank in CMAKE_MODULE_PATH

[Alan W. Irwin]

So my guess is the measures that have been used so that a blank in the
fullpath name works fine for CMake language support files that are
installed by CMake have not been extended to the case where
CMAKE_MODULE_PATH must be used to find the language support files.


I forgot to mention that the PLplot project also uses CMAKE_MODULE_PATH
to find the find modules we have implemented. That use case works
without issues when CMAKE_MODULE_PATH has a blank in the full pathname.
So such a blank only appears to be an issue when CMAKE_MODULE_PATH
is used to find language support files.

Alan

__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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] Problems with external language support when there is a blank in CMAKE_MODULE_PATH

[Alan W. Irwin]

I have been systematically testing PLplot builds for any issues with
blanks in the prefix of the source, build, and install trees, and
generally all is well under these test conditions.  However, we do
have two remaining issues which are that our (external) language
support for both Ada and D fails if there is a blank in the
source tree prefix.

Our Ada language support comes with a simple "Hello, world" test
project to test for language support issues for that language, and
I have attached a tarball of that simple project so you can
easily replicate this "blank in source tree" issue for yourself
for at least that language.

This test project works fine if the tarball is unpacked in a location
without blanks in the full pathname, but fails when there is
a blank in that unpacked pathname.

The initial error message in that latter case is

CMake Error: Could not find cmake module file: CMakeAdaInformation.cmake

Such external language support (e.g., in this Ada case) must
necessarily set CMAKE_MODULE_PATH to help CMake find the external
language support files such as CMakeAdaInformation.cmake, and that
full pathname necessarily contains a blank when the tarball is
unpacked in a location with a blank in the full pathname.

I thought the trouble might be that CMake just did not accept blanks
in the full pathname of _any_ language support files, but I
tested that case (by moving a previous CMake install location
to one with a blank in its full pathname), but a simple project
consisting of

# Test C language support
cmake_minimum_required(VERSION 3.8.1 FATAL_ERROR)
project(test_c C)

had no issues under those conditions, i.e., with
the C language support files in the /share/share/cmake-3.8/Modules/ directory tree.

So my guess is the measures that have been used so that a blank in the
fullpath name works fine for CMake language support files that are
installed by CMake have not been extended to the case where
CMAKE_MODULE_PATH must be used to find the language support files.

If that is the issue, a fix would be appreciated.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

test_ada.tar.gz
Description: Simple test case for Ada language support
-- 

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] Compile targets affected by changeset

[Florent Castelli]

> On 22 May 2017, at 20:07, Robert Patterson via cmake-developers 
>  wrote:
> 
> We understand that CMake and make already can rebuild targets which depend on 
> changed files, and this behavior works exactly as expected for us. Our issue 
> is not that make is rebuilding targets that it shouldn't. We would like this 
> 'compile targets which changed' behavior to work from a clean state, not just 
> for subsequent rebuilds. That is, from the first time cmake / make is 
> invoked, only the targets that depend on the given set of files will be 
> built, and no more.
> 
> When a developer submits a changeset to our continuous integration tool, a 
> fresh copy of the repository is checked out by the worker at the commit of 
> the changeset. We can access the set of changed files from the commit data. 
> Currently, cmake and make correctly identify that the system is in a clean 
> state and that everything should be built if the current top-level target is 
> specified. This is the point where we would like our behavior to differ. We 
> want the rebuild changed targets behavior as if everything were already 
> built, but from this clean state.
> 
> Once we have determined the targets to build, we could simply specify these 
> targets as goals to make in the command line, but we are hampered by the 
> following limitation of make.
> 
> We are using GNU make 3.82. Invoking 'make -j target1 target2 target3' on the 
> command line specifies the targets as goals to make. If several goals are 
> specified, 'make' processes each of them in turn, in the order you name them. 
> https://www.gnu.org/software/make/manual/html_node/Goals.html 
> 
> 
> Ninja does not currently work for our project.

It would be interesting to fix Ninja for your project then. Do you know what 
isn’t currently working?
Also, Ninja has some APIs to expose all the dependency graph, which you could 
probably query somehow to find out which target you need to rebuild.

Another possibility, albeit a bit different, could be to use a compilation 
cache to just rebuild everything but much faster, to the point that it might 
not be relevant anymore.

/Florent

> 
>> On May 19, 2017, at 2:32 AM, Simon Richter > > wrote:
>> 
>> Hi,
>> 
>> On 18.05.2017 23:48, Robert Patterson via cmake-developers wrote:
>> 
>>> My company has a large, predominately C++ codebase, with hundreds of
>>> targets, both for product and unit tests.  In an effort to improve the
>>> compile and test time for developers, which utilizes a continuous
>>> integration infrastructure, it is desirable to compile only the targets
>>> that are affected by developer's change sets.
>> 
>> Erm, it should already work this way. If Make rebuilds a target that it
>> shouldn't, the first step would be investigating why it thinks the
>> target needs to be rebuilt.
>> 
>> Dependency tracking is one of the oldest problems, and cmake should use
>> an appropriate solution for the actual build system you use. The
>> approach used for Make is a bit more conservative than you would require
>> for GNU Make, but should nevertheless still work.
>> 
>> http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/ 
>> 
>> 
>> is a good primer on dependency list generation with Make -- CMake
>> generates rules that are similar to these.
>> 
>>> 'make' has a limitation where if 'make target1 target2 target3' is
>>> invoked, target1, target2, and target3 are built serially, not in
>>> parallel.
>> 
>> Which version of make are you using?
>> 
>>   Simon
>> 
>> -- 
>> 
>> 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 
> 

Re: [cmake-developers] Compile targets affected by changeset

[Brad King]

On 05/18/2017 05:48 PM, Robert Patterson via cmake-developers wrote:
>  we must have a preprocessing step (makedepend or gcc -M) 

Where in your example(s) does this step take place?

> 'make' has a limitation where if 'make target1 target2 target3' is invoked,
> target1, target2, and target3 are built serially, not in parallel.

I don't think that is a limitation of `make`, but rather of CMake's
generated makefiles.  The `Makefile` files in the build tree work
internally in such a way that only one target can be built from the
command-line at a time, so they contain a `.NOTPARALLEL` mark to tell
GNU make to act serially.

> To get around this, we decided that the best option was to dynamically
> create a new [cmake] target which depends on the affected targets.

Another approach is to use `CMakeFiles/Makefile2` directly:

  make cmake_check_build_system
  make -j -f CMakeFiles/Makefile2 dir1/tgt1.dir/all dir2/tgt2.dir/all 
dir3/tgt3.dir/all

This will build all of the targets in parallel safely.  The difficulty
will be in constructing the paths to these per-target `/all` make targets.
Maybe some changes to the Unix Makefiles generator could relieve that.

Or, we could just expose an alternative entry point in the Makefile files.
It is likely not too hard to get the following to work:

  make -j cmake_targets_variable TARGETS="tgt1 tgt2 tgt3"

-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] GHS: RELEASE flags being used when CMAKE_BUILD_TYPE is empty

[Brad King]

On 05/22/2017 12:00 PM, frodak wrote:
> if CMAKE_BUILD_TYPE is not specified then only CMAKE__FLAGS
> should be used.

Correct.

-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] GHS: RELEASE flags being used when CMAKE_BUILD_TYPE is empty

[frodak]

Hello,

I ran into an issue with the Green Hills MULTI generator when the
CMAKE_BUILD_TYPE is not set.  The project files have have '-O' enabled when
compiling the software.  Looking at the generator source code I saw that it
would use the RELEASE mode flags when CMAKE_BUILD_TYPE is empty.

Based upon the CMAKE documentation it seems to me that this is incorrect
behavior and that if CMAKE_BUILD_TYPE is not specified then only
CMAKE__FLAGS should be used.

Before opening an issue report I wanted to make sure that my understanding
of these variables is correct.

Best regards,
Fred Baksik
-- 

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