> I am interested in using CMake with Green Hills MULTI
Great!
> 2. Is there a way in a toolchain file or on the command line to specify the
> directory where CMake should look for the compiler executables?
Take a look at
https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmGlobalGhsMulti
I think we should add new normalised forms but still mention the deprecated
names in the docs.
You can't put the cat back in the bag - like it or not, those option names
seem quite widely used. Developers will join a project and see them in use.
Currently they will find no mention of them in docs
On 05-Jul-16 23:26, Brad King wrote:
On 07/05/2016 04:13 PM, Ruslan Baratov wrote:
Works fine on my tests.
Thanks for testing!
However I still vote for using default value for 'fname' instead
of FATAL_ERROR.
I think that behavior would be surprising.
Not such surprising as some error in inte
On 07/05/2016 06:29 AM, Ruslan Baratov wrote:
> I don't see the point of introducing new options. Developers will still
> use -H/-B because it's backward compatible, well known and will work
> 100% because of internal CMake testing. That said if you want to improve
> the current behavior of -H/-
On 07/05/2016 04:13 PM, Ruslan Baratov wrote:
> Works fine on my tests.
Thanks for testing!
> However I still vote for using default value for 'fname' instead
> of FATAL_ERROR.
I think that behavior would be surprising.
> If something bad will happen user always can use DOWNLOAD_NAME.
>
> Exam
Thanks again, Brad!
05.07.2016, 22:58, "Brad King" :
> On date 07/05/2016 03:39 PM, Konstantin Podsvirov wrote:
>> I found a small bug in CPackIFW. The patch is attached.
>
> Thanks, applied:
>
> CPackIFW: Fix attributes for Promoting Updates repository replacement
> https://cmake.org/gitweb?p=cma
On 05-Jul-16 22:03, Brad King wrote:
On 07/01/2016 03:35 PM, Brad King wrote:
I don't think we should duplicate the
"(\\.|=)(7z|tar|tar\\.bz2|tar\\.gz|tar\\.xz|tbz2|tgz|txz|zip)$"
expression. The stripping of ?.* can be done earlier, or done as
part of the main match.
Please try this comm
On 07/05/2016 03:39 PM, Konstantin Podsvirov wrote:
> I found a small bug in CPackIFW. The patch is attached.
Thanks, applied:
CPackIFW: Fix attributes for Promoting Updates repository replacement
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7a30fa1a
> Changes are best to send to a mail
sending message
05.07.2016, 22:37, "Konstantin Podsvirov" :
Thanks, Brad!
I've been waiting for your answer :-)
05.07.2016, 22:30, "Brad King" :
> Thanks. I've merged this to next for testing.
I found a small bug in CPackIFW. The patch is attached.
I read the wrong document
On Tue, Jul 05, 2016 at 13:46:06 -0400, Brad King wrote:
> On 07/05/2016 01:31 PM, Ben Boeckel wrote:
> > Here's another idea: add an `OUTPUT_FILE ` keyword argument to
> > `file(DOWNLOAD)` to get the actual filename after content disposition
> > resolution (probably similar for 30x rewrites). This
On 07/01/2016 03:35 PM, Brad King wrote:
> I don't think we should duplicate the
>
> "(\\.|=)(7z|tar|tar\\.bz2|tar\\.gz|tar\\.xz|tbz2|tgz|txz|zip)$"
>
> expression. The stripping of ?.* can be done earlier, or done as
> part of the main match.
Please try this commit:
ExternalProject: Match
On Tue, Jul 05, 2016 at 21:01:36 +0300, Ruslan Baratov wrote:
> Well it's never too late to learn something new. Also `tar` is not
> widely used on Windows so to write nice code you should convert it to
> `cmake -E tar`. That the whole point of `cmake -E` feature.
> I don't see the problem here,
On 07/02/2016 02:21 PM, Chris Bux wrote:
> I am interested in using CMake with Green Hills MULTI.
Adding Geoffrey Viola to Cc who implemented the current GHS support.
> Should the MULTI generator provide a list of known compiler names
> by architecture, or should we rely on users to set the appro
On 05-Jul-16 20:31, Ben Boeckel wrote:
On Tue, Jul 05, 2016 at 19:49:46 +0300, Ruslan Baratov wrote:
Archive can be unpacked by "cmake -E tar xf" which detect type
automatically as far as I understand. At least this one used internally
by ExternalProject (see the testing I've made before).
CMak
On 07/05/2016 01:31 PM, Ben Boeckel wrote:
> Here's another idea: add an `OUTPUT_FILE ` keyword argument to
> `file(DOWNLOAD)` to get the actual filename after content disposition
> resolution (probably similar for 30x rewrites). This would also be
> useful for things other than ExternalProject.
T
On Tue, Jul 05, 2016 at 19:49:46 +0300, Ruslan Baratov wrote:
> Archive can be unpacked by "cmake -E tar xf" which detect type
> automatically as far as I understand. At least this one used internally
> by ExternalProject (see the testing I've made before).
CMake is not my go-to tool for extract
On 07/03/2016 09:22 AM, Dāvis Mosāns wrote:
> Huge thanks for review! Will fix mentioned issues in next version of patch.
> Also I'll implement this solution with std::streambuf as it's much better way
> and it's actually not that much work I thought it would be.
Yes, thanks Mike!
Dāvis, in the n
On 05-Jul-16 18:50, Ben Boeckel wrote:
On Tue, Jul 05, 2016 at 18:43:25 +0300, Ruslan Baratov wrote:
By default not, goes to -prefix/src/archive.tar .
Right, but if a download directory is set, this won't work. Can the
project name at least be added to the name?
If user are forcing directory th
On Tue, Jul 05, 2016 at 18:43:25 +0300, Ruslan Baratov wrote:
> By default not, goes to -prefix/src/archive.tar .
Right, but if a download directory is set, this won't work. Can the
project name at least be added to the name?
Though I'm partial to keeping the extension still; if I need to add a
p
By default not, goes to -prefix/src/archive.tar .
On 05-Jul-16 16:49, Ben Boeckel wrote:
On Tue, Jul 05, 2016 at 16:26:54 +0300, Ruslan Baratov via cmake-developers
wrote:
+ # Do not put warning message here. If everything works OK it will
+ # only distract. If unpack will fa
On Tue, Jul 05, 2016 at 16:26:54 +0300, Ruslan Baratov via cmake-developers
wrote:
> + # Do not put warning message here. If everything works OK it will
> + # only distract. If unpack will fail the standard name can be
> found in logs.
> + # (see _ep_write_extractfile_s
Got another idea. We can use default name like 'archive.tar'. Seems that
internal type of archive determined automatically and doesn't depends on
the filename. I've tried one example for each extension: 7z, tar.bz2,
tar.gz, tar.xz, tbz2, tgz, txz, zip and it just works. Patch attached.
Ruslo
On 01-Jul-16 15:58, Brad King wrote:
* Allow the form `-H -B ` with the new names.
I don't see the point of introducing new options. Developers will still
use -H/-B because it's backward compatible, well known and will work
100% because of internal CMake testing. That said if you want to imp
23 matches
Mail list logo