[cmake-developers] Dead CMake Redesign Projects

[Taylor Holberton]

Hello!

Since about July of 2018, I've been trying to design an interpreter library
for the CMake language, common for the cmake, cpack, and ctest tools. It
was my idea that I could create an extensible library for the CMake
project, that could make it easier to add commands, generators, and
integration into other scripting languages.

Today, I'm calling it quits. It turns out that, even after retrying several
times with fewer requirements, that it's just too much work for one person
(probably too much for two or three people as well.) I've uploaded all the
repositories of the several attempts I've made at doing this.

https://gitlab.kitware.com/tay10r/cmake-interpretation

The cmake-interpretation is probably the furthest I've taken any of the
projects, and was the first attempt I made at the idea. I believe I posted
this project in the mailing list as cmake-lang when I was first starting it
out. See tag 'last-known-working-state' if you try to build it.

https://gitlab.kitware.com/tay10r/cmEngine

The cmEngine project was written once in C++ and then over again in C. The
version I uploaded is the C version. The cmEngine project is neat because
the interpreter can entirely be sandboxed and the testing for it is very
elaborate (80% test coverage.) I would say this project has the best
foundation. It's also got the most documentation.

https://gitlab.kitware.com/tay10r/cmlang

This is the latest attempt at the redesign. This version has the fastest
lexer+parser by far. Rudimentary testing indicated to me that the
lexer+parser beat the one in original CMake project by a decent margin.
This is probably due to the use of memory mapping the source file and fewer
number of calls to malloc. The diagnostics in this project are probably the
best and most expressive.

Feel free to pick apart these projects anyway you choose to. I'm fine with
any of them being relicensed to Apache 2.0, MIT, or BSD (in that order of
preference) if anyone decides to use them.
-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] option to prevent in-source builds

[Taylor Holberton]

A lot of projects that use CMake already have a `./cmake` directory, I
would think `./cmake/init.json` would fit nicer as opposed to the hidden
directory. I'm not a fan of hidden directories in software projects anyway.

I would prefer an init file be written as a CMake file instead of JSON.
JSON is nice because it plays well with GUIs, but I think using CMake
syntax will function better if the file ever needs to be a bit more
complicated.

On Fri, Nov 9, 2018, 07:14 Brad King  On 11/09/2018 05:34 AM, Joachim Wuttke wrote:
> > include(PreventInSourceBuilds)
> >
> > to protect users (and myself) from unintentionally running CMake
> > in the source directory.
> >
> > Would you consider adding this little module to the CMake code base?
>
> If we are going to offer an upstream solution for this I think
> it should be done in a way that avoids ever creating any files
> (like CMakeCache.txt or CMakeFiles) in the first place.  This
> could be achieved by looking for a `.cmake/init.json` file
> at the top of the source tree with declarative information
> about the project's preferences.  One of those settings could
> reject in-source builds.
>
> -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:
> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake-developers

[cmake-developers] The "cmake_host_system_information" Command

[Taylor Holberton]

Hello!

I noticed, since 3.10, there's been several new additions to the query key
list of this command.
I understand the idea behind this command is to request information that is
non-trivial to access.
For example, FQDN takes a little bit longer than the others.

I think ideally, all variables could be accessed the same way - with a
${key} expansion.
Simple is better.

I found what I think is the class of a variable definition on GitHub.

https://github.com/tay10r/CMake/blob/dc70284c811a3183295371903d965658a9d2f8e0/Source/cmDefinitions.h#L44

If you generalize the class a bit more, you can create non-trivial
variables that make queries
when they are expanded. I made a gist demonstrating what I mean.

https://gist.github.com/tay10r/ba9f77008581732cc074c35a55d264e7
-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Happy Birthday CMake!

[Taylor Holberton]

Looked at the log in reverse and found commit 077c31484

https://gitlab.kitware.com/cmake/cmake/tree/077c31484e216a72c73370c05fcf970ce5269085

Might be fun to build this again.

On Fri, Aug 31, 2018 at 2:33 PM Bill Hoffman 
wrote:

>
> http://public.kitware.com/pipermail/insight-developers/2000-August/024248.html
>
> Thanks to everyone that has contributed or used CMake!
>
> -Bill
>
>
> --
>
> 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:
> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Alternative CMake Syntax

[Taylor Holberton]

Brad,

Thanks for your response. I've taken a little bit of time to consider your
thoughts and here is what I think.

Fair warning: Upstream is not outright opposed to a new language but
> it will take a lot to make something like that upstreamable, assuming
> we even find time to consider it in depth.
>

 That's perfectly okay. I'm willing to do the work and I've started a folder
in my repository for compatibility testing. The tests I've written so far
test
the interpreter that I've written to match the expected output you'd get
with
CMake running in script mode. I'm going to be thorough in the compatibility
tests in order to make this process easier.

A major obstacle to replacing the language is separating the code model
> representation from the current language.  Some work has been done to
> factor it out into a representation that can be used by the generators
> that is not tied to the implementation of the current language, but more
> work is needed and the original contributor working on that is no longer
> active.  Search back through the dev list archives for posts by Stephen
> Kelly talking about where his work left off.
>

I'll revisit this when I begin trying to integrate the library I've written
with
the main CMake project. Hopefully I can pick up where he left off!
Currently,
it's pretty trivial to add new functions using C++ code. I'm hoping as long
as
it stays that way, it should be pretty easy to use generator specific
functions.

If a new input language were to be introduced it should fix some of the
> fundamental problems with the current approach.  These include:
>
> * Each directory and its included files must be processed serially
>   due to the imperative language with side-effects.  This means we
>   can never make the implementation parallel.
>
> * The imperative form of the language also means that IDEs cannot
>   easily edit the build specification through GUI actions.  If at
>   least things like a list of sources were doable in a declarative
>   way that could help.
>

I agree that the affects of massive amounts of included code can be
quite noticeable but I think there's other ways to fix this than to make
the language declarative.

When thinking about alternative approaches before I've considered
> the idea of having most of the build spec be declarative/functional
> (no side effects) and then having an imperative part that computes
> parameters to evaluate conditions and expressions within the main
> spec.  The main spec could then be updated by IDEs in a structured
> way, evaluated in parallel, etc. while the imperative part could
> handle system introspection, configure-time file generation, etc.
>

Having a purely functional syntax would certainly be much easier to
execute in parallel, but I think that change would be too drastic to be
a net benefit. I wanted to make the syntax easier for system introspection
as well, since that's where it is most complicated.

The changes I have in mind are more for existing CMake code,
such as whether "()" really need to come after an "endif" keyword.
I'm going to make a more thorough survey of the CMake code and
draw examples when I write the new specification. The end goal is
to make very readable and easily maintainable CMake code, while
staying focused as a build system generating language.

The library could have facilities to make it easier for graphical front
ends to work with. For though, though, my main focus is improving
the syntax.


On Thu, Jul 5, 2018 at 8:07 AM Brad King  wrote:

> On 07/04/2018 01:08 PM, Taylor Holberton wrote:
> > I've been thinking about designing a new syntax for CMake
>
> Fair warning: Upstream is not outright opposed to a new language but
> it will take a lot to make something like that upstreamable, assuming
> we even find time to consider it in depth.
>
> > that better expresses some of the functionality that I've seen in
> > modern CMake code. I've started a CMake parsing library and plan
> > on using it to design the new syntax while maintaining support for
> > the traditional syntax as well.
>
> A major obstacle to replacing the language is separating the code model
> representation from the current language.  Some work has been done to
> factor it out into a representation that can be used by the generators
> that is not tied to the implementation of the current language, but more
> work is needed and the original contributor working on that is no longer
> active.  Search back through the dev list archives for posts by Stephen
> Kelly talking about where his work left off.
>
> If a new input language were to be introduced it should fix some of the
> fundamental problems with the current approach.  These include:
>
> * Each directory and its included files must be processed serially
>   due to the imp

[cmake-developers] Alternative CMake Syntax

[Taylor Holberton]

Hello everyone,

I've been thinking about designing a new syntax for CMake that better
expresses some of the functionality that I've seen in modern CMake code.
I've started a CMake parsing library and plan on using it to design the new
syntax while maintaining support for the traditional syntax as well.

You can read from about the project goals at
https://github.com/tay10r/cmake-lang

The new syntax will be a domain specific language. I've thought about using
Lua or similar, but I agree with one point made about a general purpose
language for CMake - it would be too tempting for programmers to turn the
build script into a monolithic system. The build system should, for the
most part, be extremely simple to read and maintain. I think a domain
specific language would accomplish this best.

I was hoping to get some input from the mailing list on what might be
desirable in a new syntax. Any information I can get would be helpful! I
don't want to come up with a new syntax without at least getting a little
bit of advice from the people who use the language the most.

Thanks in advance!
-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers

[cmake-developers] NASM Bug

[Taylor Holberton]

I noticed that CMake strips the trailing forward slash from an include
directory when assembling an object file with NASM. The trailing slash is
required with NASM. See section 2.1.16 from the NASM manual
. I've included an example that
illustrates the bug.

I copied the command text and added the trailing slash and wrote '-f elf64'
instead of '-f elf'. The command ran successfully. Then I ran `make` again
to resume the CMake build and it failed. I noticed that the Makefile was
using NASM to link the executable. I don't believe NASM has this capability.

I believe the stripping of the trailing slash and using NASM for linking
are bugs. If I'm just doing something wrong then I'd love to know how to
fix it. In the meantime, I'll just be using NASM with add_custom_command to
get the job done.


nasm-bug.tar.gz
Description: GNU Zip compressed data
-- 

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] Mini Make

[Taylor Holberton]

Hello!

I just finished the first release of a cross platform, minimalistic Make
implementation.

It was made specifically to run CMake generated Makefiles on Linux and
Windows (haven't tested on macOS yet).

It's on GitHub  and it's called Mini
Make.

Sorry for the self promotion!

If there's anyway you think it can contribute to the CMake project, feel
free to email me.
-- 

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] FindFreetype Patches

[Taylor Holberton]

Here's some patches for the FindFreetype module.
The first few patches change formatting. While the
last one extends the functionality.

-- 
Taylor Holberton
Bay Point, California
From 9307dce0496e5b24152ed796b3c4089010009d56 Mon Sep 17 00:00:00 2001
From: Taylor Holberton taylorcholber...@gmail.com
Date: Sat, 24 May 2014 21:34:01 -0700
Subject: [PATCH 1/5] Added newlines, reduced code width

---
 Modules/FindFreetype.cmake |   40 +++-
 1 file changed, 31 insertions(+), 9 deletions(-)

diff --git a/Modules/FindFreetype.cmake b/Modules/FindFreetype.cmake
index 1779b78..21904e4 100644
--- a/Modules/FindFreetype.cmake
+++ b/Modules/FindFreetype.cmake
@@ -51,7 +51,9 @@
 # wants explicit full paths and this trickery doesn't work too well.
 # I'm going to attempt to cut out the middleman and hope
 # everything still works.
-find_path(FREETYPE_INCLUDE_DIR_ft2build ft2build.h
+find_path(
+  FREETYPE_INCLUDE_DIR_ft2build
+  ft2build.h
   HINTS
 ENV FREETYPE_DIR
   PATHS
@@ -62,10 +64,14 @@ find_path(FREETYPE_INCLUDE_DIR_ft2build ft2build.h
 ENV GTKMM_BASEPATH
 [HKEY_CURRENT_USER\\SOFTWARE\\gtkmm\\2.4;Path]
 [HKEY_LOCAL_MACHINE\\SOFTWARE\\gtkmm\\2.4;Path]
-  PATH_SUFFIXES include/freetype2 include freetype2
+  PATH_SUFFIXES
+include/freetype2
+include
+freetype2
 )
 
-find_path(FREETYPE_INCLUDE_DIR_freetype2
+find_path(
+  FREETYPE_INCLUDE_DIR_freetype2
   NAMES
 freetype/config/ftheader.h
 config/ftheader.h
@@ -79,11 +85,17 @@ find_path(FREETYPE_INCLUDE_DIR_freetype2
 ENV GTKMM_BASEPATH
 [HKEY_CURRENT_USER\\SOFTWARE\\gtkmm\\2.4;Path]
 [HKEY_LOCAL_MACHINE\\SOFTWARE\\gtkmm\\2.4;Path]
-  PATH_SUFFIXES include/freetype2 include freetype2
+  PATH_SUFFIXES
+include/freetype2
+include
+freetype2
 )
 
 find_library(FREETYPE_LIBRARY
-  NAMES freetype libfreetype freetype219
+  NAMES
+freetype
+libfreetype
+freetype219
   HINTS
 ENV FREETYPE_DIR
   PATH_SUFFIXES lib
@@ -134,8 +146,18 @@ endif()
 # handle the QUIETLY and REQUIRED arguments and set FREETYPE_FOUND to TRUE if
 # all listed variables are TRUE
 include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
-FIND_PACKAGE_HANDLE_STANDARD_ARGS(Freetype
-  REQUIRED_VARS FREETYPE_LIBRARY FREETYPE_INCLUDE_DIRS
-  VERSION_VAR FREETYPE_VERSION_STRING)
+FIND_PACKAGE_HANDLE_STANDARD_ARGS(
+  Freetype
+  REQUIRED_VARS
+FREETYPE_LIBRARY
+FREETYPE_INCLUDE_DIRS
+  VERSION_VAR
+FREETYPE_VERSION_STRING
+)
+
+mark_as_advanced(
+  FREETYPE_LIBRARY
+  FREETYPE_INCLUDE_DIR_freetype2
+  FREETYPE_INCLUDE_DIR_ft2build
+)
 
-mark_as_advanced(FREETYPE_LIBRARY FREETYPE_INCLUDE_DIR_freetype2 FREETYPE_INCLUDE_DIR_ft2build)
-- 
1.7.9.5

From 6ec2c4c5f87fb03d96ad27d11da4139b96f51bec Mon Sep 17 00:00:00 2001
From: Taylor Holberton taylorcholber...@gmail.com
Date: Sat, 24 May 2014 21:35:39 -0700
Subject: [PATCH 2/5] Moved PATH_SUFFIXES argument for more consistency

---
 Modules/FindFreetype.cmake |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Modules/FindFreetype.cmake b/Modules/FindFreetype.cmake
index 21904e4..d9fbb92 100644
--- a/Modules/FindFreetype.cmake
+++ b/Modules/FindFreetype.cmake
@@ -98,7 +98,6 @@ find_library(FREETYPE_LIBRARY
 freetype219
   HINTS
 ENV FREETYPE_DIR
-  PATH_SUFFIXES lib
   PATHS
 /usr/X11R6
 /usr/local/X11R6
@@ -107,6 +106,8 @@ find_library(FREETYPE_LIBRARY
 ENV GTKMM_BASEPATH
 [HKEY_CURRENT_USER\\SOFTWARE\\gtkmm\\2.4;Path]
 [HKEY_LOCAL_MACHINE\\SOFTWARE\\gtkmm\\2.4;Path]
+  PATH_SUFFIXES
+lib
 )
 
 # set the user variables
-- 
1.7.9.5

From 6e7e2c356b17bc5139620e08c5168b09013d0b9b Mon Sep 17 00:00:00 2001
From: Taylor Holberton taylorcholber...@gmail.com
Date: Sat, 24 May 2014 21:37:28 -0700
Subject: [PATCH 3/5] Removed caps from find_package_handle_standard_args

---
 Modules/FindFreetype.cmake |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Modules/FindFreetype.cmake b/Modules/FindFreetype.cmake
index d9fbb92..278c10f 100644
--- a/Modules/FindFreetype.cmake
+++ b/Modules/FindFreetype.cmake
@@ -147,7 +147,8 @@ endif()
 # handle the QUIETLY and REQUIRED arguments and set FREETYPE_FOUND to TRUE if
 # all listed variables are TRUE
 include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
-FIND_PACKAGE_HANDLE_STANDARD_ARGS(
+
+find_package_handle_standard_args(
   Freetype
   REQUIRED_VARS
 FREETYPE_LIBRARY
-- 
1.7.9.5

From cbc682614095c2f992ceb7c9b4256dc1e9c030cc Mon Sep 17 00:00:00 2001
From: Taylor Holberton taylorcholber...@gmail.com
Date: Sat, 24 May 2014 21:38:43 -0700
Subject: [PATCH 4/5] Changed 4 to 2 space tab in version search

---
 Modules/FindFreetype.cmake |   30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/Modules/FindFreetype.cmake b/Modules/FindFreetype.cmake
index 278c10f..f892283 100644
--- a/Modules

[cmake-developers] FindFreetype Patch

[Taylor Holberton]

This patch adds windows and unix search paths that Freetype normally
installs to.

-- 
Taylor Holberton
Bay Point, California


search-paths.patch
Description: Binary data
-- 

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/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] FindFreetype Maintenance

[Taylor Holberton]

I've noticed that the FindFreetype module doesn't search standard Unix and
Windows paths. Can I add these to the find module?

As it currently stands, the module won't find Freetype in either Windows or
Linux (despite it being installed in very standard locations). It can be
overridden by creating an environment variable called FREETYPE_DIR, but I
think adding a search to standard installation paths would be preferable
for most.

-- 
Taylor Holberton
Bay Point, California
-- 

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/cgi-bin/mailman/listinfo/cmake-developers