Re: [cmake-developers] CMake aliasing system

[Tamás Kenéz]

Ruslo, I think we all could argue both against and for implementing
cmake-ini files inside the cmake command. I mean I'm also aware of all the
pros and cons. It's just that we weigh differently.
I like loosely connected simpler building blocks and my own cmake-wrapping
extension script works fine, that's why I thought you would not lose
anything with that.

>> git commit --author="John Doe" --email="john@example.com"
 --branch="master"
>> git push --remote="git://awesome.example.com"
> This is a complete nonsense!

I agree and that's why I think cmake ini files is a good idea.

Tamas

On Tue, Mar 15, 2016 at 3:25 AM, Ruslan Baratov 
wrote:

> On 15-Mar-16 02:42, Tamás Kenéz wrote:
>
> I also doubt this belongs to upstream. But you could write a single,
> generic script which forwards its arguments to cmake and also accepts and
> processes the additional parameters along the way. I don't think we'd lose
> anything:
>
> cmakeini -c ipad -H. -DTHIS_WILL_BE_FORWARDED=AS_IT_IS
>
> This is the approach I took as I needed features like you described. But
> if there would be a mature, versatile, community-tested script I'd be
> willing to use it and contribute to it.
>
> As you can see I'm already using script `build.py` and there is not enough
> power for now (even if it extends CMake basic functionality a lot) so I was
> thinking to introduce global/local ini-configuration file anyway. Then I
> realize that most of the `build.py` functions can be implemented in such
> ini-configuration. So why not use CMake? Why for example not extend CMake
> GUI with this feature support? Why do users need to install some extra
> tools instead of just one?
>
> Global/local configuration files in not something special. Git for example
> has same system, yes it increase complexity but literally every user store
> setting there.
> Just imagine you have to write something like this every commit + push:
>
> > git commit --author="John Doe" --email="john@example.com"
>  --branch="master"
> > git push --remote="git://awesome.example.com"
>
> This is a complete nonsense!
>
> So I'm planning to make a fork anyway and do some experiments even if it
> will not accepted to upstream.
>
> Ruslo
>
>
> Tamas
>
> On Mon, Mar 14, 2016 at 4:22 PM, Ruslan Baratov via cmake-developers <
> cmake-developers@cmake.org> wrote:
>
>> On 14-Mar-16 21:59, Brad King wrote:
>>
>>> On 03/12/2016 08:04 AM, Ruslan Baratov via cmake-developers wrote:
>>>
 I guess it is a well known fact that cmake command is almost never
 executed alone and for non-trivial examples usually hold some extra
 arguments (home directory, build directory, verbosity level, toolchains,
 options, ...). Also I guess that such commands doesn't change from
 day-to-day development process and an obvious way to reduce typing is to
 create wrapper build scripts (.bat or .sh, I personally use a Python
 one).

>>> Sorry, I don't think something like this belongs upstream.  It can easily
>>> be done with shell aliases or other custom scripts.
>>>
>> I've got quite opposite experience. It's hard to say that family of
>> custom scripts (+ a lot of environment variables in .bashrc)  is an "easy
>> shell scripting", example:
>> *
>> https://github.com/ruslo/polly/blob/162cd157d1d05261a7a708435197d883c4209005/bin/build.py
>>
>>We shouldn't increase the complexity of the CMake command line
>>> interface further.
>>>
>> To be clear this feature required only one new CMake option. The rest is
>> responsibility of some pre-build parsing module.
>>
>> In general I feel sad that CMake will not became more user-friendly in
>> this exact part. Though the only proves of my point that can be provided
>> here is a users experience. Since I don't see any feedback here I'm out of
>> arguments...
>>
>> Ruslo
>>
>> --
>>
>> 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: 

Re: [cmake-developers] CMake aliasing system

[Ruslan Baratov via cmake-developers]

I've openned new issue for further discussion:
* https://github.com/ruslo/CMake/issues/3

On 18-Mar-16 06:24, Tamás Kenéz wrote:
Ruslo, I think we all could argue both against and for implementing 
cmake-ini files inside the cmake command. I mean I'm also aware of all 
the pros and cons. It's just that we weigh differently.
I like loosely connected simpler building blocks and my own 
cmake-wrapping extension script works fine, that's why I thought you 
would not lose anything with that.


>> git commit --author="John Doe" --email="john@example.com" 
 --branch="master"

>> git push --remote="git://awesome.example.com "
> This is a complete nonsense!

I agree and that's why I think cmake ini files is a good idea.

Tamas

On Tue, Mar 15, 2016 at 3:25 AM, Ruslan Baratov 
> wrote:


On 15-Mar-16 02:42, Tamás Kenéz wrote:

I also doubt this belongs to upstream. But you could write a
single, generic script which forwards its arguments to cmake and
also accepts and processes the additional parameters along the
way. I don't think we'd lose anything:

cmakeini -c ipad -H. -DTHIS_WILL_BE_FORWARDED=AS_IT_IS

This is the approach I took as I needed features like you
described. But if there would be a mature, versatile,
community-tested script I'd be willing to use it and contribute
to it.

As you can see I'm already using script `build.py` and there is
not enough power for now (even if it extends CMake basic
functionality a lot) so I was thinking to introduce global/local
ini-configuration file anyway. Then I realize that most of the
`build.py` functions can be implemented in such ini-configuration.
So why not use CMake? Why for example not extend CMake GUI with
this feature support? Why do users need to install some extra
tools instead of just one?

Global/local configuration files in not something special. Git for
example has same system, yes it increase complexity but literally
every user store setting there.
Just imagine you have to write something like this every commit +
push:

> git commit --author="John Doe" --email="john@example.com"
 --branch="master"
> git push --remote="git://awesome.example.com
"

This is a complete nonsense!

So I'm planning to make a fork anyway and do some experiments even
if it will not accepted to upstream.

Ruslo



Tamas

On Mon, Mar 14, 2016 at 4:22 PM, Ruslan Baratov via
cmake-developers > wrote:

On 14-Mar-16 21:59, Brad King wrote:

On 03/12/2016 08:04 AM, Ruslan Baratov via
cmake-developers wrote:

I guess it is a well known fact that cmake command is
almost never
executed alone and for non-trivial examples usually
hold some extra
arguments (home directory, build directory, verbosity
level, toolchains,
options, ...). Also I guess that such commands
doesn't change from
day-to-day development process and an obvious way to
reduce typing is to
create wrapper build scripts (.bat or .sh, I
personally use a Python one).

Sorry, I don't think something like this belongs
upstream.  It can easily
be done with shell aliases or other custom scripts.

I've got quite opposite experience. It's hard to say that
family of custom scripts (+ a lot of environment variables in
.bashrc)  is an "easy shell scripting", example:
*

https://github.com/ruslo/polly/blob/162cd157d1d05261a7a708435197d883c4209005/bin/build.py

 We shouldn't increase the complexity of the CMake
command line interface further.

To be clear this feature required only one new CMake option.
The rest is responsibility of some pre-build parsing module.

In general I feel sad that CMake will not became more
user-friendly in this exact part. Though the only proves of
my point that can be provided here is a users experience.
Since I don't see any feedback here I'm out of arguments...

Ruslo

-- 


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: 

Re: [cmake-developers] CMake aliasing system

[Ruslan Baratov via cmake-developers]

On 15-Mar-16 02:42, Tamás Kenéz wrote:
I also doubt this belongs to upstream. But you could write a single, 
generic script which forwards its arguments to cmake and also accepts 
and processes the additional parameters along the way. I don't think 
we'd lose anything:


cmakeini -c ipad -H. -DTHIS_WILL_BE_FORWARDED=AS_IT_IS

This is the approach I took as I needed features like you described. 
But if there would be a mature, versatile, community-tested script I'd 
be willing to use it and contribute to it.
As you can see I'm already using script `build.py` and there is not 
enough power for now (even if it extends CMake basic functionality a 
lot) so I was thinking to introduce global/local ini-configuration file 
anyway. Then I realize that most of the `build.py` functions can be 
implemented in such ini-configuration. So why not use CMake? Why for 
example not extend CMake GUI with this feature support? Why do users 
need to install some extra tools instead of just one?


Global/local configuration files in not something special. Git for 
example has same system, yes it increase complexity but literally every 
user store setting there.

Just imagine you have to write something like this every commit + push:

> git commit --author="John Doe" --email="john@example.com" 
--branch="master"

> git push --remote="git://awesome.example.com"

This is a complete nonsense!

So I'm planning to make a fork anyway and do some experiments even if it 
will not accepted to upstream.


Ruslo



Tamas

On Mon, Mar 14, 2016 at 4:22 PM, Ruslan Baratov via cmake-developers 
> wrote:


On 14-Mar-16 21:59, Brad King wrote:

On 03/12/2016 08:04 AM, Ruslan Baratov via cmake-developers wrote:

I guess it is a well known fact that cmake command is
almost never
executed alone and for non-trivial examples usually hold
some extra
arguments (home directory, build directory, verbosity
level, toolchains,
options, ...). Also I guess that such commands doesn't
change from
day-to-day development process and an obvious way to
reduce typing is to
create wrapper build scripts (.bat or .sh, I personally
use a Python one).

Sorry, I don't think something like this belongs upstream.  It
can easily
be done with shell aliases or other custom scripts.

I've got quite opposite experience. It's hard to say that family
of custom scripts (+ a lot of environment variables in .bashrc) 
is an "easy shell scripting", example:

*

https://github.com/ruslo/polly/blob/162cd157d1d05261a7a708435197d883c4209005/bin/build.py

 We shouldn't increase the complexity of the CMake command
line interface further.

To be clear this feature required only one new CMake option. The
rest is responsibility of some pre-build parsing module.

In general I feel sad that CMake will not became more
user-friendly in this exact part. Though the only proves of my
point that can be provided here is a users experience. Since I
don't see any feedback here I'm out of arguments...

Ruslo

-- 


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] CMake aliasing system

[Tamás Kenéz]

I also doubt this belongs to upstream. But you could write a single,
generic script which forwards its arguments to cmake and also accepts and
processes the additional parameters along the way. I don't think we'd lose
anything:

cmakeini -c ipad -H. -DTHIS_WILL_BE_FORWARDED=AS_IT_IS

This is the approach I took as I needed features like you described. But if
there would be a mature, versatile, community-tested script I'd be willing
to use it and contribute to it.

Tamas

On Mon, Mar 14, 2016 at 4:22 PM, Ruslan Baratov via cmake-developers <
cmake-developers@cmake.org> wrote:

> On 14-Mar-16 21:59, Brad King wrote:
>
>> On 03/12/2016 08:04 AM, Ruslan Baratov via cmake-developers wrote:
>>
>>> I guess it is a well known fact that cmake command is almost never
>>> executed alone and for non-trivial examples usually hold some extra
>>> arguments (home directory, build directory, verbosity level, toolchains,
>>> options, ...). Also I guess that such commands doesn't change from
>>> day-to-day development process and an obvious way to reduce typing is to
>>> create wrapper build scripts (.bat or .sh, I personally use a Python
>>> one).
>>>
>> Sorry, I don't think something like this belongs upstream.  It can easily
>> be done with shell aliases or other custom scripts.
>>
> I've got quite opposite experience. It's hard to say that family of custom
> scripts (+ a lot of environment variables in .bashrc)  is an "easy shell
> scripting", example:
> *
> https://github.com/ruslo/polly/blob/162cd157d1d05261a7a708435197d883c4209005/bin/build.py
>
>We shouldn't increase the complexity of the CMake command line
>> interface further.
>>
> To be clear this feature required only one new CMake option. The rest is
> responsibility of some pre-build parsing module.
>
> In general I feel sad that CMake will not became more user-friendly in
> this exact part. Though the only proves of my point that can be provided
> here is a users experience. Since I don't see any feedback here I'm out of
> arguments...
>
> Ruslo
>
> --
>
> 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] CMake aliasing system

[Ruslan Baratov via cmake-developers]

On 14-Mar-16 21:59, Brad King wrote:

On 03/12/2016 08:04 AM, Ruslan Baratov via cmake-developers wrote:

I guess it is a well known fact that cmake command is almost never
executed alone and for non-trivial examples usually hold some extra
arguments (home directory, build directory, verbosity level, toolchains,
options, ...). Also I guess that such commands doesn't change from
day-to-day development process and an obvious way to reduce typing is to
create wrapper build scripts (.bat or .sh, I personally use a Python one).

Sorry, I don't think something like this belongs upstream.  It can easily
be done with shell aliases or other custom scripts.
I've got quite opposite experience. It's hard to say that family of 
custom scripts (+ a lot of environment variables in .bashrc)  is an 
"easy shell scripting", example:
* 
https://github.com/ruslo/polly/blob/162cd157d1d05261a7a708435197d883c4209005/bin/build.py



   We shouldn't increase the complexity of the CMake command line interface 
further.
To be clear this feature required only one new CMake option. The rest is 
responsibility of some pre-build parsing module.


In general I feel sad that CMake will not became more user-friendly in 
this exact part. Though the only proves of my point that can be provided 
here is a users experience. Since I don't see any feedback here I'm out 
of arguments...


Ruslo
--

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] CMake aliasing system

[Brad King]

On 03/12/2016 08:04 AM, Ruslan Baratov via cmake-developers wrote:
> I guess it is a well known fact that cmake command is almost never 
> executed alone and for non-trivial examples usually hold some extra 
> arguments (home directory, build directory, verbosity level, toolchains, 
> options, ...). Also I guess that such commands doesn't change from 
> day-to-day development process and an obvious way to reduce typing is to 
> create wrapper build scripts (.bat or .sh, I personally use a Python one).

Sorry, I don't think something like this belongs upstream.  It can easily
be done with shell aliases or other custom scripts.  We shouldn't increase
the complexity of the CMake command line interface further.

-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] CMake aliasing system

[Ruslan Baratov via cmake-developers]

Hi,

I guess it is a well known fact that cmake command is almost never 
executed alone and for non-trivial examples usually hold some extra 
arguments (home directory, build directory, verbosity level, toolchains, 
options, ...). Also I guess that such commands doesn't change from 
day-to-day development process and an obvious way to reduce typing is to 
create wrapper build scripts (.bat or .sh, I personally use a Python one).


I have next suggestion of how it can be unified: introduce ini-like file 
(say ${HOME}/.configs/cmake/alias) with alias sections with frequently 
used generators/arguments.


Example of such file:

  [default]
var: CMAKE_VERBOSE_MAKEFILE=ON
home: .
build-dir: _builds/default

  [clean]
cmd: cmake -E remove_directory _builds

  [vs-12]
inherit: default
generator: Visual Studio 12 2013
build-dir: _builds/vs-12

  [iphone]
inherit: default
generator: Xcode
build-dir: _builds/ios-9-2
var: CMAKE_TOOLCHAIN_FILE=/.../ios-9-2.cmake

  [ipad]
inherit: default
generator: Xcode
build-dir: _builds/ios-9-1
var: CMAKE_TOOLCHAIN_FILE=/.../ios-9-1.cmake

Usage:

  > cmake -c clean ipad

effectively equivalent to:

  > cmake -E remove_directory _builds
  > cmake -H. -B_builds/ios-9-2 -DCMAKE_VERBOSE_MAKEFILE=ON -GXcode 
-DCMAKE_TOOLCHAIN_FILE=/.../ios-9-2.cmake


Name of the options may be:

  -c # classes (sectioins can be inherited)
  -a # alias
  -m # meta-targets

For now it's just a thought and I have no idea how it will work on 
practice so I can create a fork for experimenting. And if it will work 
fine for me I'm planning to add such feature to CMake upstream, so I'm 
ready to hear an appropriate implementation details.


Thoughts?

Ruslo

--

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