Re: [cmake-developers] Controlling CMake GUI source/build directory from CLI

2019-01-25 Thread Gößwein Matthias / eeas gmbh
Dear Venedict,

Yes, that ist possible. Basically the syntax for cmake-gui is:

cmake-gui [] ( | )

So you can either pass a source directory or a build directory where
cmake was already run.

If you pass the path to the source directory as parameter, then cmake
uses the current directory as build directory.

So you can set both by changing to the build directory on the shell and
run cmake-gui with the source-directory as parameter from there.

However, the manual does not describe this behavior, maybe it should be
mentioned there.
(https://cmake.org/cmake/help/v3.13/manual/cmake-gui.1.html)

Best regards,
Matthias.

Am 24.01.2019 um 23:33 schrieb Venedict Tchistopolskii:
> Basically I want to launch the CMake GUI and pass in source/build
> directories through the CLI, overriding whatever it has at the moment.
>
> Is that possible? I don't get where it's picking up the previously
> touched source build but I want to override it consistently.
>
> E.g. cmake-gui.exe -H -B won't work.
>
> This is for a project wrapper that handles CMake launch and preparation.
>
> VT
>

-- 

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] "Linking" of Object Libraries

2018-05-20 Thread Gößwein Matthias / eeas gmbh
Hello,

I found a strange behavior within the object libraries in the upcoming
CMake 3.12 (I used 3.11.20180519-gdb88f for testing).

If I have for example two object libraries, which are used in one
executable:

add_library(ObjLib1 OBJECT ObjLib1.c)
target_include_directories(ObjLib1 PUBLIC ...)

add_library(ObjLib2 OBJECT ObjLib2.c)
target_include_directories(ObjLib2 PUBLIC ...)

add_executable(MyExe main.c)
target_link_libraries(MyExe ObjLib1 ObjLib2)

Then this works fine. But if for some reason one object library "links"
to the other and this is used for the executable then it does not work:

add_library(ObjLib1 OBJECT ObjLib1.c)
target_include_directories(ObjLib1 PUBLIC ...)
target_link_libraries(ObjLib1 PUBLIC ObjLib2)

add_library(ObjLib2 OBJECT ObjLib2.c)
target_include_directories(ObjLib2 PUBLIC ...)

add_executable(MyExe main.c)
target_link_libraries(MyExe ObjLib1)

I only get the usage requirements of ObjLib2, but not the object files
of ObjLib2 into the executable. If I use STATIC Libraries instead it works.
Is this behavior intended? I read the documentation too and i know that
there is no link step for object libraries, but I guess it's the same
for the static libraries (they are not linked together, instead both are
used on the link line of the executable). A similar solution would be
nice for object libraries, because otherwise the usage of object
libraries which depend on other object libraries is not working well.

Right now to get the compilation working I have to either use the
TARGET_OBJECTS generator expression at the add_executable command, or I
have to link explicit to ObjLib2 for the executable:

add_executable(MyExe main.c $)

or

target_link_libraries(MyExe ObjLib1 ObjLib2)

For both possibilities I have to repeat in some sort the dependency and
it gets worse if the depth of the dependencies is going deeper.

Best regards,
Matthias.


-- 

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] new generator question - xml file output for embedded IDE platforms.

2018-05-02 Thread Gößwein Matthias / eeas gmbh
Hi Duane,

As far as i understand from your mail you want to generate project files
from CMake.

Although I would appreciate a more powerful configure_file command (e.g.
a built in generator like the mustache generator
(https://mustache.github.io/) or something like that) i must confess
that configure_file is not the right command for the feature you want.
It is used to generate some files from templates (e.g. Header Files),
actually in a simple form of exchanging placeholders with contents of a
CMake Variables.

It works like that:

The feature which you want is done by the CMake Generators, which you
can specify by the command line option -G  (or you can select
it with the cmake-gui).
If an IDE is actually not supported by CMake a generator it will have to
be implemented for that in the source code of CMake. There are
generators which generate IDE projects, where you can build it with the
IDE itselt (e.g. Visual Studio) and there are so called "Extra
generators" which generate Ninja/Makefiles and additional project files
for the IDE. The build can be done by the IDE, but it will run the
Ninja/Makefiles (e.g. Eclipse CDT generator).
https://cmake.org/cmake/help/v3.11/manual/cmake-generators.7.html

The Toolchain and the Processor (Chip) may be specified by Toolchain
Files, which can also be chosen by the cmake-gui or on the command line
with the option -T . You may have several toolchain
files for different toolchains (e.g. one for embedded and one for PC)

Some information regarding that can be found here:
https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/CrossCompiling
https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html

When CMake is run it checks for a working compiler. To check that CMake
tries to compile a simple program. For embedded compilers it is not
always possible without some special files (e.g. linker files), so CMake
also provides a special mode for that where only a library is created
instead of an executable.
(See Variable CMAKE_TRY_COMPILE_TARGET_TYPE,
https://cmake.org/cmake/help/v3.11/variable/CMAKE_TRY_COMPILE_TARGET_TYPE.html)

Best regards,
Matthias.

-- 
matthias.goessw...@eeas.at /mail
www.eeas.at /web
+43 660 1280 131 /phone

--
eeas gmbh
Technologiepark 17
4320 Perg
Austria

--
ATU67456549 /uid
FN385458a /firmenbuchnummer
landesgericht linz /firmenbuch

Am 01.05.2018 um 22:50 schrieb du...@duaneellis.com:
> Hi - 
>
> I'm looking into adding a new "generator" type, that is basically a
> fancy form of "configure_file()"
>
> At this point, I've been stepping through Cmake code trying to
> understand the general flow
> and want to ask the question: Is this insane or stupid? Or not a bad
> idea.
>
> Some details to understand where I am headed and what I'm thinking.
>
> Generally, cmake produces a makefile, or - for example with Visual
> Studio it produces an XML file directly.
>
> In my case, I am focusing on micro-controller *embedded* targets - and I
> need to produce various XML files that are required by IDEs.
> In other cases I need to create GNU makefiles for command line gcc-arm
> it varies.
>
> I also need the ability to create Visual Studio (or linux) projects
> because it is often very helpful to create unit tests for libraries that
> can run on a host platform for some embedded libraries - it is this unit
> test part that makes Cmake is an interesting solution.
>
> For the EMBEDDED target - some assumptions & major compromises for this
> type of target is important and must be made - ie: You cannot compile
> and execute something, many of the various tests and such will just not
> be possible.  The IDEs often cannot really manage re-running Cmake  -
> (basically some IDEs perform an IMPORT operation)
>
> To simplify - I want to limit the supported items to two things: 
>  Build (1 to N) static libraries.
>  Build & Link (1 to N) applications, typically this produces an ELF
> file
>  Optionally extract a HEX or BIN file from the ELF file.
>
> The IDEs generally have:
>A top level Workspace file - Much like a Visual Studio SLN file.
>Each project has its own file - much like visual studio.
>There are sometimes additional files to be created
>Something for the debugger, or perhaps a "config.h" type file
>
> The goal here is not just compiling the code but fully supporting the
> IDE experience, ie: all debugger features work better if you build using
> the IDE
>
> My hunch is this:
>  What is really needed is a TEMPLATE language - and to some degree
> that is what I am proposing and want feed back on.
>
> Assume the following is present, ie: on the command line or via a
> CMakeLists.txt file in a subdirectory
> A variable with the TOOL NAME (with version number)
> A variable with the CHIP NAME
>
> Then - 
> Based on the TOOL & CHIP NAME - I can find (and read) other files
> with more details.
> For example Endian, specific ARCH ie: ARM CortexM3 vrs 

[cmake-developers] Usage Requirements with Object Libraries

2018-04-11 Thread Gößwein Matthias / eeas gmbh
Hello,

Right now I'm using a nightly build (3.11.20180407-g268d0) to use and
test the Usage Requirements with Object Libraries, which is planned for
CMake 3.12.0 (https://gitlab.kitware.com/cmake/cmake/issues/14778)

It's working great so far, but I if i have a construct of two object
libraries, which depend in some way of each other I get an error message:

CMake Error: The inter-target dependency graph contains the following
strongly connected component (cycle):
  "lib1" of type OBJECT_LIBRARY
    depends on "lib2" (strong)
  "lib2" of type OBJECT_LIBRARY
    depends on "lib1" (weak)
At least one of these targets is not a STATIC_LIBRARY.  Cyclic
dependencies are allowed only among static libraries.

CMakeLists.txt:

add_library(lib1 OBJECT lib1.c)
target_link_libraries(lib1 PUBLIC lib2)
add_library(lib2 OBJECT lib2.c)
target_link_libraries(lib2 PUBLIC lib1)


If i use Static libraries, then it works (in fact even if only one
library is an object library it fails). Is it possible to implement the
same thing for object libraries too, or are there some technical
restrictions?
In the past i had sometimes such cyclic dependencies with legacy code
and i think it would be great if it is possible to support such
dependencies with object libraries as well.

Best regards,
Matthias Goesswein.

-- 
matthias.goessw...@eeas.at /mail
www.eeas.at /web
+43 660 1280 131 /phone

--
eeas gmbh
Technologiepark 17
4320 Perg
Austria

--
ATU67456549 /uid
FN385458a /firmenbuchnummer
landesgericht linz /firmenbuch


-- 

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