Re: [CMake] Complaint about if..endif

[cyril_wobow]

Andreas Schneider a écrit :

On Sunday 23 November 2008 17:43:53 cyril_wobow wrote:
  

Sure, I guess we are all here because CMake is a very powerful suite,
with tons of functionalities and useful abstractions. But I challenge
anyone to seriously tell me that he/she enjoys writing CMake script. As
soon as you don't have to only set a bunch of variables and call a few
built-in macros any more, you get crazy. Do a bit of string processing,
you get crazy. Write/call your own functions and macros, with argument
passing and returning, you get crazy.



I haven't had problems reading CMake files yet. Maybe it depends on the 
programmer who writes the CMake files. My first CMake project was Wengophone 
(now Qutecom).


  

To me, that is definitely THE weakest point of CMake, along with its
fairly arnarchic documentation.



Well I've started to learn CMake just with reading the manpage. All you need 
is in there. Well there are some people who are not used to read manpages. I 
think that is the problem.


However there is #cmake @ freenode for those who need help.

Cheers,


-- andreas

  



___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


I should really not be feeding trolls but here is a quick reply.

It surely depends on the programmer. And it does not matter. All I say 
is that it is kind of a pity to have such a powerful tool and such a 
poor scripting facility. I may be using CMake partly for what it is 
*not* (i.e. some advanced-ish build scripting) and I swear to god, I 
suffer doing that. I may be a mediocre build engineer (I prefer spending 
my time developing), but I still dream of the perfect build system that 
even I could use.


Thanks for your constructive spirit,

Cyril
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Complaint about if..endif

[Andreas Schneider]

On Sunday 23 November 2008 17:43:53 cyril_wobow wrote:
> Sure, I guess we are all here because CMake is a very powerful suite,
> with tons of functionalities and useful abstractions. But I challenge
> anyone to seriously tell me that he/she enjoys writing CMake script. As
> soon as you don't have to only set a bunch of variables and call a few
> built-in macros any more, you get crazy. Do a bit of string processing,
> you get crazy. Write/call your own functions and macros, with argument
> passing and returning, you get crazy.

I haven't had problems reading CMake files yet. Maybe it depends on the 
programmer who writes the CMake files. My first CMake project was Wengophone 
(now Qutecom).

> To me, that is definitely THE weakest point of CMake, along with its
> fairly arnarchic documentation.

Well I've started to learn CMake just with reading the manpage. All you need 
is in there. Well there are some people who are not used to read manpages. I 
think that is the problem.

However there is #cmake @ freenode for those who need help.

Cheers,


-- andreas

-- 
http://www.cynapses.org/ - cybernetic synapses


signature.asc
Description: This is a digitally signed message part.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Complaint about if..endif

[Michael Jackson]

On Nov 23, 2008, at 11:43 AM, cyril_wobow wrote:


Robert Dailey a écrit :
On Sun, Nov 23, 2008 at 4:20 AM, cyril_wobow <[EMAIL PROTECTED] > wrote:


   Like a ... python front end ?

   Seriously, cmake is really, really, really verbose and terribly
   unreadable as a scripting language...


I would agree with you in that CMake isn't perfect and it does have  
a lot of issues that I've seen in the few hours I've spent learning  
it. It has some issues with portability and it also is pretty  
unreadable/verbose in some cases. However, considering alternatives  
I would say it could be worse. Boost.Build (BJam) is absolutely one  
of the most unreadable languages I've seen. I refuse to use it just  
because of that fact. I also have yet to find another build system  
that generates visual studio project files like CMake does. It  
would be nice to see alternatives for comparison though.
Sure, I guess we are all here because CMake is a very powerful  
suite, with tons of functionalities and useful abstractions. But I  
challenge anyone to seriously tell me that he/she enjoys writing  
CMake script. As soon as you don't have to only set a bunch of  
variables and call a few built-in macros any more, you get crazy. Do  
a bit of string processing, you get crazy. Write/call your own  
functions and macros, with argument passing and returning, you get  
crazy.
To me, that is definitely THE weakest point of CMake, along with its  
fairly arnarchic documentation.

I would be very interested by others' testimonies.
Kudos anyway to the CMake team!


While there are certainly some areas where CMake could be improved  
upon the general cross platform support is better than any  
alternatives. And the alternatives are not very pleasing...


If I have a project that I need to compile on Windows (MinGW and  
MSVC), OS X, and Linux my choices are:

  CMake
   OR
Makefiles for Linux/MinGW
Xcode Project for OS X (or reuse the Makefiles)
MSVC Projects for Windows.

Now say that I don't know makefiles and only a passing familiarity  
with Visual Studio. What am I to do? I can use CMake and be reasonably  
confident for my project that I can get a working Visual studio,  
makefiles and Xcode project generated for each.


  Or better yet, what if I was at a small company where the linux/os  
x guy left and I was a windows guy who didn't know _anything_ about OS  
X or linux. Who would keep those projects updated? What if it was  
OpenSource? Now you have to find another willing contributor to keep  
everything up to date for the missing build systems..


  The documentation is another issue all together. I think it could  
be massively improved but unfortunately I do not have the time to lend  
a hand. I have given what I can (Qt Assistant based docs) that allow  
one to more easily look for commands, properties and variables but  
that is about it.


  Having started to update the current implementation of boost's  
cmake build system it is becoming apparent that CMake is lacking in  
some areas where bjam has the same functionality. This stems from the  
fact that a lot of time is spent on making sure bjam works to build  
boost so of course bjam has functionality used by boost.build. If that  
same time was spent getting the CMake system working for boost then I  
don't think there would be as many issues.


Obviously CMake scales, just look at the KDE project. They selected  
CMake and it _seems_ to be working for them. Andreas can probably add  
some more here.


In summary for my projects (Qt, Command line based, HDF5/XML projects)  
and for the number of employees I have (me) CMake is a very large time  
saver over the alternatives.


Just my 2 cents

_
Mike Jackson  [EMAIL PROTECTED]
BlueQuartz Softwarewww.bluequartz.net
Principal Software Engineer  Dayton, Ohio



___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Complaint about if..endif

[Eric NOULARD]

Le Sun, 23 Nov 2008 17:43:53 +0100,
cyril_wobow <[EMAIL PROTECTED]> a écrit :

> Robert Dailey a écrit :
> > On Sun, Nov 23, 2008 at 4:20 AM, cyril_wobow <[EMAIL PROTECTED] 
> > > wrote:
> >
> > Like a ... python front end ?
> >
> > Seriously, cmake is really, really, really verbose and terribly
> > unreadable as a scripting language...
> >
> >
> > I would agree with you in that CMake isn't perfect and it does have
> > a lot of issues that I've seen in the few hours I've spent learning
> > it. It has some issues with portability and it also is pretty 
> > unreadable/verbose in some cases. However, considering alternatives
> > I would say it could be worse. Boost.Build (BJam) is absolutely one
> > of the most unreadable languages I've seen. I refuse to use it just 
> > because of that fact. I also have yet to find another build system 
> > that generates visual studio project files like CMake does. It
> > would be nice to see alternatives for comparison though.
> Sure, I guess we are all here because CMake is a very powerful suite, 
> with tons of functionalities and useful abstractions. But I challenge 
> anyone to seriously tell me that he/she enjoys writing CMake script.
> As soon as you don't have to only set a bunch of variables and call a
> few built-in macros any more, you get crazy. Do a bit of string
> processing, you get crazy. Write/call your own functions and macros,
> with argument passing and returning, you get crazy.
> To me, that is definitely THE weakest point of CMake, along with its 
> fairly arnarchic documentation.
> I would be very interested by others' testimonies.
> Kudos anyway to the CMake team!

I do use CMake for some time now (something 2 years+).
I think is the best build system I know today.

CMake language is simple but this is NOT a scripting language.
As far as I remember CMake developer word (on ML) CMake was
designed as a _DECLARATIVE_ language:
  add_executable
  add_library
  install
  ...

So doing loop, string manipulation or any other 
non-declarative algorithmic computation is at best _weird_
even if it has been greatly improved with 2.6.x
(see PARENT_SCOPE for set, FUNCTION, ENDIF() ...)

I tend to do as much as I can do using CMake script,
for example my small CPackRPM contribution to CMake 
http://www.vtk.org/Wiki/CMake:CPackPackageGenerators#RPM_.28Unix_Only.29
is almost all done in CMake scripts which a minimalist part in C++.

I did it this way because modification is easier without recompiling
CMake :-)

Now when I have to do some may be complex algorithmic things 
I first try doing it in scripts which is now easier each time
I do it because I gain experience.

Not to say that CMake scripting is pleasant, I would rather
go for python if I had a choice, however I manage to do what
I want with CMake, but my current project are not that big.
http://www.ohloh.net/projects/6472
http://www.ohloh.net/projects/6471

I think I don't need complex algorithmic features for my build process.
It may be far different for testing.
I'm using CTest too, but there I tend to write python scripts
which are launched by CTest
ADD_TEST(MyComplexTest wonderPythonScript.py)

My question to your usage would be, in which case do you need
complex function in your build system?
-- 
Erk
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Complaint about if..endif

[cyril_wobow]

Robert Dailey a écrit :
On Sun, Nov 23, 2008 at 4:20 AM, cyril_wobow <[EMAIL PROTECTED] 
> wrote:


Like a ... python front end ?

Seriously, cmake is really, really, really verbose and terribly
unreadable as a scripting language...


I would agree with you in that CMake isn't perfect and it does have a 
lot of issues that I've seen in the few hours I've spent learning it. 
It has some issues with portability and it also is pretty 
unreadable/verbose in some cases. However, considering alternatives I 
would say it could be worse. Boost.Build (BJam) is absolutely one of 
the most unreadable languages I've seen. I refuse to use it just 
because of that fact. I also have yet to find another build system 
that generates visual studio project files like CMake does. It would 
be nice to see alternatives for comparison though.
Sure, I guess we are all here because CMake is a very powerful suite, 
with tons of functionalities and useful abstractions. But I challenge 
anyone to seriously tell me that he/she enjoys writing CMake script. As 
soon as you don't have to only set a bunch of variables and call a few 
built-in macros any more, you get crazy. Do a bit of string processing, 
you get crazy. Write/call your own functions and macros, with argument 
passing and returning, you get crazy.
To me, that is definitely THE weakest point of CMake, along with its 
fairly arnarchic documentation.

I would be very interested by others' testimonies.
Kudos anyway to the CMake team!
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Complaint about if..endif

[Eric NOULARD]

Le Sun, 23 Nov 2008 12:15:06 +1100,
"Jack Andrews" <[EMAIL PROTECTED]> a écrit :

> hi rob,
> 
> > Why must endif() contain the same expression as the associated if()
> > command?
> 
> i think this could be the most noticed feature of cmake (in the five
> minute test).  as noted, in other posts, you don't have to any more.
> but i've been thinking of creating another, less verbose, front end
> for cmake.  fortunately, cmake has a clear interface to the backends
> (the local generators) so such a work is made a whole lot easier.

There was some discussion some time ago regarding adding
more "frontend" language to CMake:

May be you can look at:

http://www.cmake.org/Wiki/CMake:Experiments_With_Lua
and the companion thread on the ML:
http://www.cmake.org/pipermail/cmake/2007-November/017971.html


-- 
Erk
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Complaint about if..endif

[Robert Dailey]

On Sun, Nov 23, 2008 at 4:20 AM, cyril_wobow <[EMAIL PROTECTED]> wrote:
>
> Like a ... python front end ?
>
> Seriously, cmake is really, really, really verbose and terribly unreadable
> as a scripting language...
>

I would agree with you in that CMake isn't perfect and it does have a lot of
issues that I've seen in the few hours I've spent learning it. It has some
issues with portability and it also is pretty unreadable/verbose in some
cases. However, considering alternatives I would say it could be worse.
Boost.Build (BJam) is absolutely one of the most unreadable languages I've
seen. I refuse to use it just because of that fact. I also have yet to find
another build system that generates visual studio project files like CMake
does. It would be nice to see alternatives for comparison though.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Complaint about if..endif

[cyril_wobow]

Jack Andrews a écrit :

hi rob,

  

Why must endif() contain the same expression as the associated if() command?



i think this could be the most noticed feature of cmake (in the five
minute test).  as noted, in other posts, you don't have to any more.
but i've been thinking of creating another, less verbose, front end
for cmake.  fortunately, cmake has a clear interface to the backends
(the local generators) so such a work is made a whole lot easier.


ta, jack
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
  


Like a ... python front end ?

Seriously, cmake is really, really, really verbose and terribly 
unreadable as a scripting language...

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Complaint about if..endif

[Jack Andrews]

hi rob,

> Why must endif() contain the same expression as the associated if() command?

i think this could be the most noticed feature of cmake (in the five
minute test).  as noted, in other posts, you don't have to any more.
but i've been thinking of creating another, less verbose, front end
for cmake.  fortunately, cmake has a clear interface to the backends
(the local generators) so such a work is made a whole lot easier.


ta, jack
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Complaint about if..endif

[Bill Hoffman]

Ioan Calin Borcoman wrote:

Does this apply to else(), too?

And could you please update the man page?



In cmake 2.6.0 and greater the arguments are optional.

if(foo AND BAR)
...
endif()

works just fine without the variable being set.

-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Complaint about if..endif

[Ioan Calin Borcoman]

Does this apply to else(), too?

And could you please update the man page?

Thanx.

Ionutz

On Sat, Nov 22, 2008 at 7:53 AM, Philip Lowman <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 22, 2008 at 12:17 AM, Robert Dailey <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> Why must endif() contain the same expression as the associated if()
>> command? Isn't CMake smart enough to know that a simple occurrence of
>> "endif()" simply matches the previous if(), regardless of its expression
>> list? Are there any plans to simplify this? The way it is now is redundant
>> and boilerplate.
>
> On CMake 2.6.x you no longer have to match the endif().  If you're still
> using CMake 2.4.x you can set CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS.
>
> http://www.vtk.org/Wiki/CMake_Useful_Variables
>
>
> --
> Philip Lowman
>
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Complaint about if..endif

[Philip Lowman]

On Sat, Nov 22, 2008 at 12:17 AM, Robert Dailey <[EMAIL PROTECTED]> wrote:

> Hi,
>
> Why must endif() contain the same expression as the associated if()
> command? Isn't CMake smart enough to know that a simple occurrence of
> "endif()" simply matches the previous if(), regardless of its expression
> list? Are there any plans to simplify this? The way it is now is redundant
> and boilerplate.


On CMake 2.6.x you no longer have to match the endif().  If you're still
using CMake 2.4.x you can set CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS.

http://www.vtk.org/Wiki/CMake_Useful_Variables


-- 
Philip Lowman
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake