Re: [CMake] Suddendly missing members when compiling on macOS Mojave

[Juan Sanchez]

I had an issue last week, where the isysroot setting was messed up, after I
had done an xcode update.

Even though I am using Mojave (10.14), instead of Catalina (10.15), xcode
has apparently upped the version number from 10.14 to 10.15.

 /Applications/Xcode.app/Contents/Developer/Platforms/
MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk

Creating a brand new build directory fixed the problem, since the cached
information concerning the compiler environment was invalid.

Regards,

Juan


On Fri, Nov 8, 2019 at 10:18 AM Ruben Di Battista 
wrote:

> Hello,
>
> Tryign to compile a project that built correctly since now. I guess
> something changed on my system, and now I’m getting this error:
>
> Scanning dependencies of target Mercurve
> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f
> src/libs/CMakeFiles/Mercurve.dir/build.make
> src/libs/CMakeFiles/Mercurve.dir/build
> [  4%] Building CXX object
> src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o
> cd /Users/rubendibattista/git/x/Mercurve/build/src/libs &&
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
>  -DMercurve_EXPORTS -I/Users/rubendibattista/git/x/Mercurve/src/libs
> -isystem /opt/local/include/vtk-8.1 -isystem /opt/local/include -isystem
> /opt/local/include/mpich-mp -isystem /opt/local/include/libxml2  -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
> -mmacosx-version-min=10.14 -fPIC   -std=gnu++11 -o
> CMakeFiles/Mercurve.dir/BlockMerger.cxx.o -c
> /Users/rubendibattista/git/x/Mercurve/src/libs/BlockMerger.cxx
> In file included from
> /Users/rubendibattista/git/x/Mercurve/src/libs/BlockMerger.cxx:21:
> In file included from
> /Users/rubendibattista/git/x/Mercurve/src/libs/BlockMerger.h:28:
> In file included from
> /Users/rubendibattista/git/x/Mercurve/src/libs/types.h:25:
> In file included from
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/unordered_set:363:
> In file included from
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__hash_table:19:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:314:9:
> error: no member named 'signbit' in the global namespace
> using ::signbit;
>   ~~^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:315:9:
> error: no member named 'fpclassify' in the global namespace
> using ::fpclassify;
>   ~~^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:316:9:
> error: no member named 'isfinite' in the global namespace
>
> Something got messed up with Xcode update I guess. I also tried to
> downgrade Xcode without success. Does anyone have hints on how to solve
> this? In particular I’m not entirely sure that the `-isysroot` flag the
> cmake provides is correct anymore. Is that possible?
>
>   _
> -. .´  |
>   ',  ;|∞∞
> ˜˜ |∞ RdB
> ,.,|∞∞
>   .'   '.  |
> -'   `’
> https://rdb.is
>
> --
>
> 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
>
-- 

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

Re: [CMake] How to Switch to Static Runtime on Command Line?

[Juan Sanchez]

Hello,

It has been a while since I've looked at this stuff, but I do use
exceptions in my project.  So I add the /EHsc:
SET (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /fp:strict /EHsc
${WARNINGS_IGNORE}")
SET (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /fp:strict ${WARNINGS_IGNORE}")

and I also add a linker flag:
SET (CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /SAFESEH:NO")
SET (CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} /SAFESEH:NO
/NODEFAULTLIB:python3")
SET (CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS} /SAFESEH:NO")

According to the M$ documentation, SAFESEH is relevant for x86, but not x64:
https://docs.microsoft.com/en-us/cpp/build/reference/safeseh-image-has-safe-exception-handlers?view=vs-2019

In order to change runtimes, I have also had to enable defaultlib's in case
they got in through other libraries or header files:
SET (CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS}
/NODEFAULTLIB:LIBCMT")

According to this instruction you can disable all of the libraries you do
not want:
https://docs.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-warning-lnk4098?view=vs-2019

For example, above I had to do:
/NODEFAULTLIB:python3

because the Python header files in my project were force linking the wrong
library.

Regards









On Mon, Oct 28, 2019 at 6:02 AM Osman Zakir 
wrote:

> Hi.
>
> I'm trying to build LLVM 10.0.0 with CMake on the command line (Developer
> Command Prompt for VS2019) and I need to know how to switch to a static
> runtime.  I've tried specifying LLVM's variable for this, but it didn't
> work.  I still have a dynamic runtime.  Along with that, I also need to
> know how to enable C++ exceptions.
>
> One thing I tried was to do "-DCMAKE_CXX_FLAGS="/std:c++17 /MT /EHsc
> /permissive-"" but this also didn't work.  Specifying these on the CXXFLAGS
> environment variable didn't do anything either.  I was using the same
> session of the Developer Command Prompt, but I made sure to run
> "refreshenv" to take the new environment from the registry before
> continuing.
>
> Note: I don't want to edit the CMakeLists.txt file because I want to be
> able to run "git pull" without having to stage any changes (I cloned the
> LLVM GitHub repository for the source code).
>
> Any help is appreciated.  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
>
-- 

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

Re: [CMake] CMake link order

[Juan Sanchez]

Hello,

I have always used all of the libraries at once to the
TARGET_LINK_LIBRARIES command.

In the following example, the link line order appears the same as the
libraries are listed on the line.

TARGET_LINK_LIBRARIES(devsim_tcl ${LIBRARIES} ${TCL_ARCHIVE}
${SUPERLU_ARCHIVE} ${BLAS_ARCHIVE} ${SQLITE3_ARCHIVE}
${SYMDIFF_ARCHIVE} ${OPTIONAL_LIBS} ${PTHREAD_LIB} ${DLOPEN_LIB})

This is important because my LIBRARIES need to all be on the link line
before the other libraries I am using.

Another option is to explicitly us ADD_DEPENDENCY to add dependencies
between the libraries:
https://cmake.org/cmake/help/latest/command/add_dependencies.html

If I had multiple libraries hopelessly intertwined, I would list them
multiple times:
A B A C

or force the linker to do multiple passes:

 -Wl,--start-group A B C  -Wl,--end-group

This is by using the start-group and end-group flags in your
TARGET_LINK_LIBRARIES line.
https://cmake.org/pipermail/cmake/2011-May/044478.html

Regards,

Juan






On Fri, Oct 18, 2019 at 9:56 AM Bon, William 
wrote:

> Hello,
>
> we are facing an issue while using cmake and we have no idea how to solve
> or debug it.
> We have a complex and huge project (about 50 subdirectories and
> dependencies everywhere), and we are facing issue regarding the link order.
> There is a lot of dependencies between those projects, and to summarize,
> we have two libraries A and B
> A is an imported library from headers and shared lib .so declared like this
> ```
> add_library(A SHARED IMPORTED GLOBAL)
> set_target_properties(A PROPERTIES
> IMPORTED_LINK_INTERFACE_LANGUAGES "C"
> IMPORTED_LOCATION ${A_LIBRARY})
> ```
>
> B is a system library part of a package.
>
> We need to link A before B in every case.
>
> In every project, we include A before B using
> ```
> find_package(B)
> target_link_libraries(${library_produced} PUBLIC A)
> target_link_libraries(${library_produced} PUBLIC B)
> ```
>
> but from time to time, we don't know why, the library produced link in the
> wrong order (checked with ldd and make VERBOSE=1).
> it links B before A.
>
> Is there a way to find out what happens and why cmake change the link
> order for some project and not all projects ?
>
> Best regards,
>
> 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
>
-- 

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

Re: [CMake] Single library with both shared and static binaries

[Juan Sanchez]

Here is an example where two libraries are created from object files that
have only been compiled once:

ADD_LIBRARY(symdiff_objects OBJECT ${CXX_SRCS} ${MC_SRCS})
set_property(TARGET symdiff_objects PROPERTY POSITION_INDEPENDENT_CODE ON)
ADD_LIBRARY(symdiff_dynamic STATIC $)
ADD_LIBRARY(symdiff SHARED $)

The "symdiff_dynamic" library is a static archive that can then be linked
into another shared library or an executable. The "symdiff" library is a
standalone object.  The POSITION_INDEPENDENT_CODE property is required for
the linux platform, but not for macOS or Windows.  If the original poster
is comfortable with having a PIC static library, this is an approach they
can take.

Regards,

Juan

On Wed, Sep 25, 2019 at 8:43 AM Kyle Edwards via CMake 
wrote:

> On Tue, 2019-09-24 at 23:41 +0300, Avraham Shukron wrote:
> > Hi!
> >
> > I have a library which I want to distribute in both shared object and
> > static library forms.
> > Is there a modern way to do it without creating two completely
> > separate library targets?
> > Since I want to be a good CMake citizen I use `target_*` and
> > `set_target_properties` as much as possible, and creating two
> > different libraries will force me to duplicate that information about
> > each one of them.
> >
> > I also tries not specifying STATIC/SHARED, and then running cmake
> > twice - once with BUILD_SHARED_LIBS=ON and once OFF and then
> > installing to the same directory. I got my both .a and .so libraries
> > installed, but I couldn't get the Config file correctly for this
> > arrangement.
> >
> > So - what is the community-recommended pattern to do this?
>
> Unfortunately, the recommendation is to do exactly what you don't want
> to do: create a shared target and a static target.
>
> To make this slightly simpler, you can use functions to de-duplicate
> the target_* and set_target_properties calls:
>
> function(create_foo_target name type)
>   add_library(${name} ${type} foo.c foo.h)
>   set_target_properties(${name} OUTPUT_NAME foo)
> endfunction()
>
> create_foo_target(foo_shared SHARED)
> create_foo_target(foo_static STATIC)
>
> Kyle
> --
>
> 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
>
-- 

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

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Juan Sanchez]

>From my brief research, it looks like the Microsoft version of CMake may
have Ninja support.

https://devblogs.microsoft.com/cppblog/cmake-support-in-visual-studio-whats-new-in-2017-15-3-update/


Regards,

Juan

On Tue, Sep 17, 2019 at 1:36 PM Joao Pedro Abreu De Souza <
jp_ab...@id.uff.br> wrote:

> So, only the Visual Studio generator use the Arch option? I try generate
> ninja build, but cmake(3.15.3) and the answer was
>
> ```
> $ cmake -B build -S . -G "Ninja" -A Win32
> CMake Error at CMakeLists.txt:2 (project):
>   Generator
>
> Ninja
>
>   does not support platform specification, but platform
>
> Win32
>
>   was specified.
>
>
> CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
> CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
> -- Configuring incomplete, errors occurred!
> See also
> "C:/Users/jpabreu/Desktop/testCMAKE/build/CMakeFiles/CMakeOutput.log".
> ```
>
> Em ter, 17 de set de 2019 às 14:00, Juan Sanchez 
> escreveu:
>
>> Hello,
>>
>> My impression that targeting 32 bit depends on what generator you are
>> using.
>>
>> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html
>>
>> It looks like cmake now has:
>>
>>- cmake -G "Visual Studio 15 2017" -A Win32
>>- cmake -G "Visual Studio 15 2017" -A x64
>>
>> It used to be that the default target platform was Win32, and  you had to
>> specify Win64 in the generator string to target a 64 bit build.  For
>> example with Visual Studio 2015
>>
>>
>> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html
>>
>> For compatibility with CMake versions prior to 3.1, one may specify a
>> target platform name optionally at the end of the generator name. This is
>> supported only for:
>> Visual Studio 14 2015 Win64Specify target platform x64.Visual Studio 14
>> 2015 ARMSpecify target platform ARM.
>>
>>
>> Regards,
>>
>> Juan
>>
>>
>> On Tue, Sep 17, 2019 at 7:18 AM Joao Pedro Abreu De Souza <
>> jp_ab...@id.uff.br> wrote:
>>
>>> cl from visual studio 2017.
>>>
>>> Em ter, 17 de set de 2019 03:26, Stéphane Ancelot <
>>> sance...@numalliance.com> escreveu:
>>>
>>>> Hi,
>>>>
>>>> That first depends on which compiler you will use ?
>>>>
>>>> Regards,
>>>>
>>>> S.Ancelot
>>>> Le 16/09/2019 à 22:32, Joao Pedro Abreu De Souza a écrit :
>>>>
>>>> Hi guys. I am trying to generate,using cmake, a executable with target
>>>> Windows 32 bits using Windows 64 bits, but cannot find a standard toolchain
>>>> file (I find to Linux, to Android, but can't find to Windows 32 bits) to
>>>> build. Do you know some repository of toolchain files that has Windows 32
>>>> bits from Windows 64 bits? Or maybe someone has a standard toolchain file
>>>> to this type of thing.
>>>>
>>>> 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
>>>
>>
-- 

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

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Juan Sanchez]

Hello,

My impression that targeting 32 bit depends on what generator you are using.
https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html

It looks like cmake now has:

   - cmake -G "Visual Studio 15 2017" -A Win32
   - cmake -G "Visual Studio 15 2017" -A x64

It used to be that the default target platform was Win32, and  you had to
specify Win64 in the generator string to target a 64 bit build.  For
example with Visual Studio 2015

https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html

For compatibility with CMake versions prior to 3.1, one may specify a
target platform name optionally at the end of the generator name. This is
supported only for:
Visual Studio 14 2015 Win64Specify target platform x64.Visual Studio 14 2015
 ARMSpecify target platform ARM.


Regards,

Juan


On Tue, Sep 17, 2019 at 7:18 AM Joao Pedro Abreu De Souza <
jp_ab...@id.uff.br> wrote:

> cl from visual studio 2017.
>
> Em ter, 17 de set de 2019 03:26, Stéphane Ancelot <
> sance...@numalliance.com> escreveu:
>
>> Hi,
>>
>> That first depends on which compiler you will use ?
>>
>> Regards,
>>
>> S.Ancelot
>> Le 16/09/2019 à 22:32, Joao Pedro Abreu De Souza a écrit :
>>
>> Hi guys. I am trying to generate,using cmake, a executable with target
>> Windows 32 bits using Windows 64 bits, but cannot find a standard toolchain
>> file (I find to Linux, to Android, but can't find to Windows 32 bits) to
>> build. Do you know some repository of toolchain files that has Windows 32
>> bits from Windows 64 bits? Or maybe someone has a standard toolchain file
>> to this type of thing.
>>
>> 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
>
-- 

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

Re: [CMake] system runtime library file does not exist (warning)

[Juan Sanchez]

Hello,

Somewhat related to your issue, is that newer versions of the Intel MKL are
now free for use:
https://software.intel.com/en-us/articles/free-ipsxe-tools-and-libraries

Free Intel Performance Libraries
 for *Everyone*

*Free for all, no royalties, no restrictions on company or project size,
access to current & older versions of libraries (only current version for
Intel® MPI), Forum Support.*

Regards,

Juan

On Tue, Sep 17, 2019 at 5:46 AM Ilias Miroslav, doc. RNDr., PhD. <
miroslav.il...@umb.sk> wrote:

> Hello,
>
> I have recent CMake 3.15.2 and old MKL library 11.1.
>
> Upon configuration cmake is issuing warnings due to faulty determined
> folder of general name  FOLDER_lin (proper name is without lin):
>
> CMake Warning at
> /home/milias/bin/cmake/cmake-3.15.2-Linux-x86_64/share/cmake-3.15/Modules/InstallRequiredSystemLibraries.cmake:684
> (message):
>   system runtime library file does not exist:
>   '/mnt/apps/intel/composer_xe_2013_sp1.1.106/compiler/lib/intel64*_lin*
> /irml'
> Call Stack (most recent call first):
>   cmake/custom/cpack-dirac.cmake:1 (include)
>   CMakeLists.txt:85 (include)
>
> while proper MKL folder is:
>
> ls /mnt/apps/intel/composer_xe_2013_sp1.1.106/compiler/lib/intel64/
> cilk_db.so* libcilkrts.so.5*libcomposerxe_rdmgr_2.1.so*
>  libimf.so*  libistrconv.so*
> codecov_libFNP.so*  libcomposerxe_boost_date_time_1.34.so*
> libdecimal.a*libintlc.so*  libmatmul.a*
> crt/  libcomposerxe_boost_filesystem_1.34.so*  libicaf.so*
>  libintlc.so.5* liboffload.so*
> for_main.o* libcomposerxe_boost_regex_1.34.so*  libifcore.a*
>  libiomp5.a*  liboffload.so.5*
> icc_libFNP.so* libcomposerxe_boost_system_1.34.so*  libifcore.so*
>libiomp5.dbg*  libomp_db.so*
> icpc_libFNP.so* libcomposerxe_boost_thread_1.34.so*
>  libifcore.so.5*libiomp5.so*  libpdbx.a*
> ifort_libFNP.so*libcomposerxe_cfgmgr_2.4.so*  libifcore_pic.a*
>  libiompstubs5.a*   libpdbx.so*
> init.o*  libcomposerxe_clpt_3.1.so*   libifcoremt.a*
>  libiompstubs5.so*  libpdbx.so.5*
> irml/  libcomposerxe_cpil_2.10.so*   libifcoremt.so*
>  libipgo.a*  libpdbxinst.a*
> libbfp754.a* libcomposerxe_gen_helpers_core_2.3.so*
> libifcoremt.so.5*libirc.a*  libsvml.a*
> libchkp.so* libcomposerxe_gen_helpers_das_2.3.so*
>  libifcoremt_pic.alibirc.so*  libsvml.so*
> libchkpwrap.a* libcomposerxe_libxml_2.7.so*  libifport.a*
>  libirc_s.a*  locale/
> libchkpwrap_w.a*libcomposerxe_msngr_cmd_2.4.so*  libifport.so*
>  libirng.a*  ofldbegin.o*
> libcilkrts.a* libcomposerxe_msngr_reader_2.4.so*  libifport.so.5*
>libirng.so*  ofldend.o
> libcilkrts.so* libcomposerxe_msngr_util_2.4.so*  libimf.a*
> libistrconv.a* tselect_libFNP.so*
>
> This is only warning, maybe InstallRequiredSystemLibraries.cmake could be
> updated for that.
>
> Best,
>
> Miro
> --
>
> 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
>
-- 

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

Re: [CMake] Setting RPATH lookup on macOS

[Juan Sanchez]

I never suggested copying files into the build tree.  The original
question was about how to locate libraries at runtime.  You don't
necessarily have to use @rpath, @executable_path is also a valid
option.  Another valid option one is to strip out @rpath and use
DYLD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH.

If you want to set an rpath from cmake, you can also use target properties like:
INSTALL_RPATH
BUILD_WITH_INSTALL_RPATH

where BUILD_WITH_INSTALL_RPATH is useful if you don't want to use
CMake's install system.

Regards,

Juan

On Thu, Sep 12, 2019 at 10:56 AM Michael Jackson
 wrote:
>
> On macOS you really should _not_ have to copy the libraries into the build 
> tree. I have never had to do that in 10 years of our product (Windows is a 
> different story). The trick is setting the correct options to add in the 
> paths to the libraries into the RPATH of the executable/library. (at least on 
> macOS & Linux systems).
>
>
>
> --
>
> Mike Jackson
>
>
>
>
>
> From: Juan Sanchez 
> Date: Thursday, September 12, 2019 at 11:35 AM
> To: Michael Jackson 
> Cc: CMake 
> Subject: Re: [CMake] Setting RPATH lookup on macOS
>
>
>
> The macOS install_name_tool can be used to change the RPATH of your binaries. 
>  It can also be used to set the path for each of the libraries to be loaded.  
> For a python module I compile, I copy each of its dylib into the appropriate 
> directory relative to my shared library.  I then use the install_name_tool to 
> change from an absolute path to a path relative to @loader_path.
>
>
>
> install_name_tool -change $j "@loader_path/../gcc/`basename $j`" $i
>
> where $j is the full path output from "otool -L" and "@loader_path/../gcc" 
> would point to a directory "gcc" relative to the directory containing my 
> python module.
>
> For a binary executable, I would explore placing required dylib files into a 
> directory relative to @executable_path.
>
> Regards,
>
>
>
> Juan
>
>
>
> On Wed, Sep 11, 2019 at 4:33 PM Michael Jackson  
> wrote:
>
> Already looked on google and at the CMake documentation but everything listed 
> does not seem to work so here is the setup.
>
> I am using MKL and I have a home grown FindMKL since there isn’t an official 
> one. Inside that is the typical find_library() calls which will find the 
> libraries just fine. One of those libraries is a dynamic library (.dylib). 
> Using otool -L on that library the install_name is encoded as @rpath.
>
> Now I have my add_executable(foo…) and target_link_libraries (Foo 
> ${MKL_LIBRARIES} ).
>
> Everything compiles and links fine. The issue is at runtime. The app will not 
> launch because libmkl_rt.dylib is not loaded because the path to that library 
> is not encoded into the executable.
>
> 639:[mjackson@ferb:ifort-release]$ otool -l 
> Bin/EMsoftWorkbench.app/Contents/MacOS/EMsoftWorkbench | grep "path"
>  name @rpath/libEbsdLib.dylib (offset 24)
>  name @rpath/libmkl_rt.dylib (offset 24)
>  name @rpath/QtOpenGL.framework/Versions/5/QtOpenGL (offset 24)
>  name @rpath/QtNetwork.framework/Versions/5/QtNetwork (offset 24)
>  name @rpath/QtConcurrent.framework/Versions/5/QtConcurrent (offset 
> 24)
>  name @rpath/QtWidgets.framework/Versions/5/QtWidgets (offset 24)
>  name @rpath/QtGui.framework/Versions/5/QtGui (offset 24)
>  name @rpath/QtCore.framework/Versions/5/QtCore (offset 24)
>  path /Users/Shared/EMsoft_SDK-ifort/EbsdLib-0.1-Release/lib (offset 
> 12)
>  path /Users/Shared/EMsoft_SDK-ifort/Qt5.12.3/5.12.3/clang_64/lib 
> (offset 12)
>
>
> Oddly the Qt libraries and one of my own libraries do get their rpaths 
> encoded. I feel like I need to append to the RPATH that gets encoded into the 
> executable but I am not really figuring out how to do that.
>
> Help
>
> --
> Michael Jackson | Owner, President
>   BlueQuartz Software
> [e] mike.jack...@bluequartz.net
> [w] www.bluequartz.net <http://www.bluequartz.net>
>
>
> --
>
> 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:
> h

Re: [CMake] Setting RPATH lookup on macOS

[Juan Sanchez]

The macOS install_name_tool can be used to change the RPATH of your
binaries.  It can also be used to set the path for each of the libraries to
be loaded.  For a python module I compile, I copy each of its dylib into
the appropriate directory relative to my shared library.  I then use the
install_name_tool to change from an absolute path to a path relative to
@loader_path.

install_name_tool -change $j "@loader_path/../gcc/`basename $j`" $i
where $j is the full path output from "otool -L" and "@loader_path/../gcc"
would point to a directory "gcc" relative to the directory containing my
python module.

For a binary executable, I would explore placing required dylib files into
a directory relative to @executable_path.

Regards,

Juan



On Wed, Sep 11, 2019 at 4:33 PM Michael Jackson 
wrote:

> Already looked on google and at the CMake documentation but everything
> listed does not seem to work so here is the setup.
>
> I am using MKL and I have a home grown FindMKL since there isn’t an
> official one. Inside that is the typical find_library() calls which will
> find the libraries just fine. One of those libraries is a dynamic library
> (.dylib). Using otool -L on that library the install_name is encoded as
> @rpath.
>
> Now I have my add_executable(foo…) and target_link_libraries (Foo
> ${MKL_LIBRARIES} ).
>
> Everything compiles and links fine. The issue is at runtime. The app will
> not launch because libmkl_rt.dylib is not loaded because the path to that
> library is not encoded into the executable.
>
> 639:[mjackson@ferb:ifort-release]$ otool -l
> Bin/EMsoftWorkbench.app/Contents/MacOS/EMsoftWorkbench | grep "path"
>  name @rpath/libEbsdLib.dylib (offset 24)
>  name @rpath/libmkl_rt.dylib (offset 24)
>  name @rpath/QtOpenGL.framework/Versions/5/QtOpenGL (offset 24)
>  name @rpath/QtNetwork.framework/Versions/5/QtNetwork (offset 24)
>  name @rpath/QtConcurrent.framework/Versions/5/QtConcurrent
> (offset 24)
>  name @rpath/QtWidgets.framework/Versions/5/QtWidgets (offset 24)
>  name @rpath/QtGui.framework/Versions/5/QtGui (offset 24)
>  name @rpath/QtCore.framework/Versions/5/QtCore (offset 24)
>  path /Users/Shared/EMsoft_SDK-ifort/EbsdLib-0.1-Release/lib
> (offset 12)
>  path /Users/Shared/EMsoft_SDK-ifort/Qt5.12.3/5.12.3/clang_64/lib
> (offset 12)
>
>
> Oddly the Qt libraries and one of my own libraries do get their rpaths
> encoded. I feel like I need to append to the RPATH that gets encoded into
> the executable but I am not really figuring out how to do that.
>
> Help
>
> --
> Michael Jackson | Owner, President
>   BlueQuartz Software
> [e] mike.jack...@bluequartz.net
> [w] www.bluequartz.net 
>
>
> --
>
> 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
>
-- 

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

Re: [CMake] Question about getting git branch name.

[Juan Sanchez]

Hello,

https://stackoverflow.com/questions/1417957/show-just-the-current-branch-in-git

suggests:

git rev-parse --abbrev-ref HEAD

Regards,

Juan


On Sat, Jun 8, 2019 at 5:25 PM Steven Truppe  wrote:

> Hi everyone,
>
> i want to have code lines like:
>
> #define BUILD_VERSION
>
> and the BUILD_VERSION should be the name of the actual branch the code
> was compiled with, this way i can create a branch for each version and
> name it like 0.1 so each version i'm using for release is an own branch.
>
> I found many examples that shows me the branch name (like git status)
> but i don't know a way to get only the name of the current branch so i
> can for example execute_process to get the revision number into a
> variable and then use add_definition(..) to add it as a compile definition.
>
>
> best regards!
>
> --
>
> 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
>
-- 

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

Re: [CMake] How to use Ninja on Windows with MSVC?

[Juan Sanchez]

On Wed, May 22, 2019 at 10:27 AM Michael Jackson <
mike.jack...@bluequartz.net> wrote:

> Do this all the time both for our CDash nightlies and when I am developing
> on Windows. The essential pieces of the puzzle are the following:
>
> 1: Ninja needs to be on your path
> 2: The compilers need to be on your path.
>
> 1 can be solved in a few different ways. The brute force is to edit the
> system path variable and place the folder containing Ninja into the system
> path. I do NOT recommend doing this. Repeat. DON'T DO IT. You can edit your
> "User" PATH environment variable and add to the PATH. This is the more
> recommended way but a bit tedious to get into that dialog box to adjust. We
> will come back to this..
>
> For 2, use the "Visual Studio Command Prompt" which has all the paths to
> the compilers setup for you. Now the question becomes, how to combine 1 and
> 2. My own solution (which is far from optimal, but works) is that I setup
> my own "short cut" to a command prompt that launches my own custom .bat
> file that sits on my desktop. In that .bat file is basically a copy of the
> vcvarsall.bat file and then I add to that my own specific PATH values for
> things like Qt, hdf5, cmake, ninja that on located on my system. I keep
> both the shortcut and the .bat file on my desktop so all I need to do is
> double click to get a correctly configured command prompt for my dev
> environment. If a version of something changes I just edit the .bat file
> and I am ready to go. You can then also do "cmake-gui.exe ." from inside a
> build folder to have CMake-Gui launch with all the correctly identified
> compilers.
>

For this option, you can use the batch command, "call", to read in the
environment of another ".bat" script, so that you do not have to make
copies of the vcvarsall.bat files.  As long as you are not using "setlocal"
in a script, then the environment variables will propagate up to the caller.

 For example your script can have (for VS 2015) :
call "%VS140COMNTOOLS%VsVars32.bat"

and the add lines setting additional PATH values.

Regards,

Juan



>
> I am happy to share the .bat file if you are interested. I have it updated
> for VS2017 at the moment but have been doing it this way since VS2013.
>
> --
> Michael Jackson | Owner, President
>   BlueQuartz Software
> [e] mike.jack...@bluequartz.net
> [w] www.bluequartz.net 
>
> On 5/22/19, 9:58 AM, "CMake on behalf of Robert Dailey" <
> cmake-boun...@cmake.org on behalf of rcdailey.li...@gmail.com> wrote:
>
> From the command line, I want to generate Ninja build scripts that
> utilize a specific version of MSVC compiler. Basically I'd like the
> combination of `-G"Visual Studio 15 2017"` with regards to its ability
> to find the C and C++ compiler on the system via registry/environment
> variables, and `-G"Ninja"` with regards to it being the build driver
> for that compiler.
>
> Is this even possible?
> --
>
>
>
> --
>
> 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
>
-- 

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

Re: [CMake] [EXTERNAL] Re: Linking to boost on OS X 10.12

[Juan Sanchez]

Hello,

How are you adding the library?  Are you using "-L /path/to/boost/libs
-lboost_foo" syntax when using target_link_libraries?  What do you see when
running "otool -L" on the resulting executable?  If you still need to run
install_name_tool, I suppose you can do it using a POST_BUILD cmake command.
https://cmake.org/cmake/help/v3.13/command/add_custom_command.html

Regards,

Juan


On Wed, Feb 6, 2019 at 11:32 AM Stephens, J. Adam 
wrote:

> Hi Juan,
>
>
>
> I believe BUILD_WITH_INSTALL_RPATH would place the correct RPATH in the
> executables. It’s a potentially easier alternative to using the BUILD_RPATH
> property for that purpose. However, I think it’s only half of what needs to
> happen. The linker still would be unable to find the boost libraries
> because their install names do not contain @rpath. Thanks for the
> suggestion.
>
>
>
> --
>
> J. Adam Stephens, Ph.D.
>
> Dakota Support Analyst
>
> https://dakota.sandia.gov/
>
> Optimization and UQ
>
> Sandia National Laboratories
>
> Albuquerque, NM
>
>
>
>
>
> *From: *Juan Sanchez 
> *Date: *Tuesday, February 5, 2019 at 3:37 PM
> *To: *"Stephens, J. Adam" 
> *Cc: *"Maynard, Robert (External Contact)" , "
> cmake@cmake.org" 
> *Subject: *Re: [CMake] [EXTERNAL] Re: Linking to boost on OS X 10.12
>
>
>
> Hello,
>
>
>
> Are you able to use BUILD_WITH_INSTALL_RPATH:
>
> https://cmake.org/cmake/help/v3.13/prop_tgt/BUILD_WITH_INSTALL_RPATH.html
>
>
> https://cmake.org/cmake/help/v3.13/prop_tgt/INSTALL_RPATH.html#prop_tgt:INSTALL_RPATH
>
>
>
> Regards,
>
>
>
> Juan
>
>
>
>
>
> On Tue, Feb 5, 2019 at 4:00 PM Stephens, J. Adam via CMake <
> cmake@cmake.org> wrote:
>
> Hi Robert,
>
> Thanks for your reply. We do use install_name_tool and the like when
> installing/packaging, and our packages continue to work fine on OS X 10.12.
> My question is about what to do with executables before packaging, while
> they are still just in the build tree. We need them to work for purposes of
> testing via CTest.
>
> Adam
>
>
> On 2/5/19, 2:56 PM, "Robert Maynard"  wrote:
>
> My general approach for the second problem is to run a tool such as
> install_name_tool to change the library names to have @rpath when
> constructing the package.
>
> On Tue, Feb 5, 2019 at 2:25 PM Stephens, J. Adam via CMake
>  wrote:
> >
> > Hello,
> >
> >
> >
> > The project I work on links to several shared boost libraries. After
> our organization disallowed use of OS X 10.11 and we upgraded our
> built/test slave to 10.12, we encountered a problem with our testing.
> Executables in the build tree that were built as part of our project now
> fail to run with the error that boost libraries can’t be found.
> >
> >
> >
> > Superficially, the problem is that (I think) Apple strengthened the
> SIP between 10.11 and 10.12 to prevent DYLD_LIBRARY_PATH from having any
> effect – previously the linker was able to locate the boost libs for our
> build tree executables that way.
> >
> >
> >
> > The deeper problem is twofold: First, the build tree executables
> don’t include the boost lib folder in their RPATHs. Second, the install
> names embedded in boost libs themselves are just the bare filenames with no
> @rpath. (My understanding is, the boost project does that deliberately
> because they can’t know what users of their libraries will want.)
> >
> >
> >
> > Recent versions of CMake (3.8+) have the property BUILD_RPATH that
> we could use to embed the path to the boost libs into the build tree
> executables. That doesn’t solve the second part of the problem, though.
> Without embedding install names that look like @rpath/libboost_foo.dylib in
> the build tree executables, I think the linker will still be unable to find
> them.
> >
> >
> >
> > What is the best (or least bad) way to fix this?
> >
> >
> >
> > Thanks!
> >
> >
> >
> > Adam
> >
> >
> >
> > --
> >
> > J. Adam Stephens, Ph.D.
> >
> > Dakota Support Analyst
> >
> > https://dakota.sandia.gov/
> >
> > Optimization and UQ
> >
> > Sandia National Laboratories
> >
> > Albuquerque, NM
> >
> >
> >
> > --
> >
> > Powered by www.kitware.com
&

Re: [CMake] [EXTERNAL] Re: Linking to boost on OS X 10.12

[Juan Sanchez]

Hello,

Are you able to use BUILD_WITH_INSTALL_RPATH:
https://cmake.org/cmake/help/v3.13/prop_tgt/BUILD_WITH_INSTALL_RPATH.html
https://cmake.org/cmake/help/v3.13/prop_tgt/INSTALL_RPATH.html#prop_tgt:INSTALL_RPATH

Regards,

Juan


On Tue, Feb 5, 2019 at 4:00 PM Stephens, J. Adam via CMake 
wrote:

> Hi Robert,
>
> Thanks for your reply. We do use install_name_tool and the like when
> installing/packaging, and our packages continue to work fine on OS X 10.12.
> My question is about what to do with executables before packaging, while
> they are still just in the build tree. We need them to work for purposes of
> testing via CTest.
>
> Adam
>
>
> On 2/5/19, 2:56 PM, "Robert Maynard"  wrote:
>
> My general approach for the second problem is to run a tool such as
> install_name_tool to change the library names to have @rpath when
> constructing the package.
>
> On Tue, Feb 5, 2019 at 2:25 PM Stephens, J. Adam via CMake
>  wrote:
> >
> > Hello,
> >
> >
> >
> > The project I work on links to several shared boost libraries. After
> our organization disallowed use of OS X 10.11 and we upgraded our
> built/test slave to 10.12, we encountered a problem with our testing.
> Executables in the build tree that were built as part of our project now
> fail to run with the error that boost libraries can’t be found.
> >
> >
> >
> > Superficially, the problem is that (I think) Apple strengthened the
> SIP between 10.11 and 10.12 to prevent DYLD_LIBRARY_PATH from having any
> effect – previously the linker was able to locate the boost libs for our
> build tree executables that way.
> >
> >
> >
> > The deeper problem is twofold: First, the build tree executables
> don’t include the boost lib folder in their RPATHs. Second, the install
> names embedded in boost libs themselves are just the bare filenames with no
> @rpath. (My understanding is, the boost project does that deliberately
> because they can’t know what users of their libraries will want.)
> >
> >
> >
> > Recent versions of CMake (3.8+) have the property BUILD_RPATH that
> we could use to embed the path to the boost libs into the build tree
> executables. That doesn’t solve the second part of the problem, though.
> Without embedding install names that look like @rpath/libboost_foo.dylib in
> the build tree executables, I think the linker will still be unable to find
> them.
> >
> >
> >
> > What is the best (or least bad) way to fix this?
> >
> >
> >
> > Thanks!
> >
> >
> >
> > Adam
> >
> >
> >
> > --
> >
> > J. Adam Stephens, Ph.D.
> >
> > Dakota Support Analyst
> >
> > https://dakota.sandia.gov/
> >
> > Optimization and UQ
> >
> > Sandia National Laboratories
> >
> > Albuquerque, NM
> >
> >
> >
> > --
> >
> > 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
>
>
> --
>
> 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
>
-- 

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

Re: [CMake] CMake with Lua Experiment

[Juan Sanchez]

Brandon Van Every wrote:
 On Nov 27, 2007 2:32 PM, Brandon Van Every [EMAIL PROTECTED] wrote:
 On Nov 26, 2007 3:55 PM, Brandon Van Every [EMAIL PROTECTED] wrote:
 I noticed the unpack command.

 sources = {
   simpleLib.cxx,
   simpleCLib.c,
   simpleWe.cpp
 }

 cm_add_library (simpleLib, STATIC, unpack(sources));

 Would this be necessary / paradigmatic in Lua?  In CMake I just use lists.
 Reading the Lua docs, it seems one uses a table instead of a list.
 There's a shorthand for calling a function that has 1 table as its
 argument: f{whatever} instead of f({whatever}).  So I think the above
 could have been:

 cm_add_library{simpleLib, STATIC, simpleLib.cxx, simpleCLib.c,
 simpleWe.cpp}

 and of course the function would have to handle the table
 appropriately.
 
 Lua also has a varargs interface via ... so there's no reason this has
 to be done with a table.  But I guess you knew that already.  So, the
 real wart is that in CMake we only have to type ${sources} and in Lua
 we'd have to type unpack(sources) all the time.  That's gonna get old.
 
 Now I'll see if we can get rid of all those pointless quotes.
 
 It doesn't look possible.  That's annoying.

How about?

cm_add_library{simpleLib STATIC simpleLib.cxx simpleCLib.c simpleWe.cpp}


Regards,

Juan

 
 
 Cheers,
 Brandon Van Every
 ___
 CMake mailing list
 CMake@cmake.org
 http://www.cmake.org/mailman/listinfo/cmake
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] CMake with Lua Experiment

[Juan Sanchez]

Alexander Neundorf wrote:
 On Tuesday 27 November 2007, Juan Sanchez wrote:
 ...
 How about?

 cm_add_library{simpleLib STATIC simpleLib.cxx simpleCLib.c simpleWe.cpp}
 
 Are you sure putting it all in one quoted string will make getting the 
 quoting 
 right simpler than it is now ?

Please remember the context:
On Nov 27, 2007 2:32 PM, Brandon Van Every [EMAIL PROTECTED] wrote:
 cm_add_library{simpleLib, STATIC, simpleLib.cxx, simpleCLib.c,
 simpleWe.cpp}
.
.
.
.
 Now I'll see if we can get rid of all those pointless quotes.

I was specifically talking about the lua api and offer suggestions
concerning Brandon's dislike for quotation marks and commas.  Of course
cmake's current language is simpler.  The goal of course is to have a
language which is well documented, popular, self-consistent, and not
home-made.

Of course, I'd much prefer Tcl, but everyone else hates it.  However, if
Lua takes off, it will be much better than what we have now.

Juan



 Alex
 ___
 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] CMake with Lua Experiment

[Juan Sanchez]

Brandon Van Every wrote:
 On Nov 27, 2007 3:22 PM, Juan Sanchez [EMAIL PROTECTED] wrote:
 How about?

 cm_add_library{simpleLib STATIC simpleLib.cxx simpleCLib.c simpleWe.cpp}
 
 That paradigm is crippled with respect to FOREACH and LIST style
 processing.  I can't really see everyone on the CMake script side of
 things doing it one way, and the Lua side of things doing it another
 way.  Plus it doesn't help for strings within strings.
 
 I'm starting to realize that general purpose programming languages
 don't care about ease of string entry.  Whereas shell / make / build
 tools have a history of making strings easy at the expense of other
 programming constructs.

The reason I suggested Tcl was it makes strings easy.  Most everything
is a string in Tcl.  There are also no commas, parenthesis, or quotation
marks.  Everyone hates Tcl, and I accept that.

For those of you who don't know enough about Tcl to hate it, please
check out:

http://en.wikipedia.org/wiki/Tcl#Syntax

My only desire is that we move on to another language better than the
one we have now.  Lua seems to fit the bill.

Juan


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

Re: [CMake] Applying command to source files

[Juan Sanchez]

If I remember the original intent, I thought the desire was to enforce
some draconian indenting policy.

Shouldn't that be a script in your source code management tool?  For
example, the indentation policy will be enforced the moment the file is
checked in.

Juan

Eric Noulard wrote:
 2007/11/15, Mike Jackson [EMAIL PROTECTED]:
 What about looking at the FindQt4.cmake file. Aren't there macros
 that run 'moc' over a list of files and produce new source code files
 from that? Might be a good place to start...
 
 I did that.
 But those MACROS take source file lists as argument
 and I would like to avoid to manually respecify files which have
 already been specified in ADD_LIBRARY or ADD_EXECUTABLE.
 
 2007/11/16, Brandon Van Every [EMAIL PROTECTED]:
 On Nov 15, 2007 3:04 PM, Eric Noulard [EMAIL PROTECTED] wrote:
 I currently lack a command which could give me
 all sources files in a directory.
 FILE(GLOB ... ?
 
 Yep. You are right.
 I will do that if I have no other mean to get the list of file
 which was _already_ specified in ADD_LIBRARY and ADD_EXECUTABLE.
 
 To be more precise I was thinking of something like:
 
 GET_DIRECTORY_PROPERTY(SRCFILES
 DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
 SOURCES_FILES)
 
 or
 
 GET_DIRECTORY_PROPERTY(SRCFILES
 DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
 SOURCES_FILES
 LANG CXX)
 
 Which is not currently available.



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

Re: [CMake] Applying command to source files

[Juan Sanchez]

Eric Noulard wrote:
 2007/11/16, Juan Sanchez [EMAIL PROTECTED]:
 If I remember the original intent, I thought the desire was to enforce
 some draconian indenting policy.
 
 Draconian :=)
 Not really I'll consider this homogeneous in order
 to avoid stupid editor configuration config spurious difference
 but that's not the issue.
 
 Shouldn't that be a script in your source code management tool?  For
 example, the indentation policy will be enforced the moment the file is
 checked in.
 
 Yes your are damn right, and I did this in the past.
 
 But, the fact is the concerned project is hosted on a server
 where I have not enough privilege to run such scripts
 for security reason.
 
 I don't think that popular project hosting service
 like Sourceforge, BerliOS, Savannah do authorize such user scripts.
 
Apparently sourceforge supports commit scripts.

http://sourceforge.net/docs/E04/#scripts

Juan


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

Re: [CMake] Applying command to source files

[Juan Sanchez]

James Bigler wrote:
 Eric Noulard wrote:
 2007/11/16, Juan Sanchez [EMAIL PROTECTED]:

 Shouldn't that be a script in your source code management tool?  For
 example, the indentation policy will be enforced the moment the  
 file is
 checked in.
 Yes your are damn right, and I did this in the past.

 But, the fact is the concerned project is hosted on a server
 where I have not enough privilege to run such scripts
 for security reason.

 I don't think that popular project hosting service
 like Sourceforge, BerliOS, Savannah do authorize such user scripts.

 Apparently sourceforge supports commit scripts.

 http://sourceforge.net/docs/E04/#scripts
 
 That may work for CVS, but sourceforge doesn't allow any custom  
 scripts for subversion repositories.
 
 http://sourceforge.net/docman/display_doc.php? 
 docid=31070group_id=1#scripts


But if you ask nicely, they may install it for you.  Quoting the bottom
of section 09 in your link.
quote
To request additional hook scripts be installed for use, submit a
Feature Request.
/quote

It seems to be a popular paradigm.

Juan





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

Re: [CMake] CMake Book ?

[Juan Sanchez]

I had bought mine a few months ago from kitware directly.

http://www.kitware.com/products/cmakebook.html

Their shopping cart system seems to be down, for all of their books, and
not just the cmake one.

Juan

Pau Garcia i Quiles wrote:
 Quoting Stephen Collyer [EMAIL PROTECTED]:
 
 I'm finding the information in the wiki too scattered to
 find out what I need to know about cmake easily, but the
 cmake book no longer seems to be available. Anyone know
 where I can get hold of one ? Or does someone have one that
 they want to get rid of ?
 
 Hey, good to see you here :-)
 
 I guess they are preparing a new edition of the book.
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] Link question

[Juan Sanchez]

Alexander Neundorf wrote:
 On Monday 12 November 2007, Xavier Larrode wrote:
 Hi all,
 Is there a way in cmake to link (in linux) to a .so lib wich is not
 prefix by lib.
 So link to a lib without the -lmyLib
 
 To a library which is already installed on the system ?
 I think this doesn't work, the linker won't find the file mylib.so if you (or 
 cmake) say -lmylib.

Try using the full path and name of the lib you'd like to add in the
TARGET_LINK_LIBRARIES command.

I've done this before with external libraries, and I think at least one
of them may not have had the lib prefix.

If that doesn't work, try SET_TARGET_PROPERTIES with the LINK_FLAGS you
want.

Juan

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


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] Automatic dependency scanner of CMake 2.4.7

[Juan Sanchez]

According to the FAQ:
http://www.cmake.org/Wiki/CMake_FAQ#CMake_dependency_scanner

#if 0 shouldn't work either.

How was the programming bad?  Both /* */ comments and conditional
statements are handled equally well by the c pre processor.

Since each C/C++ compiler has a cpp, wouldn't it be good to adopt the
dependency scanner to use cpp underneath?

Thanks,

Juan

Hendrik Sattler wrote:
 Am Sonntag 11 November 2007 schrieb [EMAIL PROTECTED]:
 I am using CMake version 2.4-patch 7 on Linux/Debian, and I noticed that
 a the automatic dependency scanner of CMake does add a dependency on the
 file bar.cpp upon the file foo.h when it encounters a the following
 commented out preprocessor command inside the bar.cpp file:

 /*
 #include foo.h
 */
 
 The dependency scanner in cmake is not very exact but better more then less.
 Your programming isn't good either. Did you try the following?
 #if 0
 #include foo.h
 #endif
 
 HS
 ___
 CMake mailing list
 CMake@cmake.org
 http://www.cmake.org/mailman/listinfo/cmake
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] Linking problem

[Juan Sanchez]

Hello,

There a much nicer platform independent writeup on this at:

http://www.cmake.org/Wiki/CMake_FAQ#Does_that_mean_I_have_to_build_all_my_library_objects_twice.2C_once_for_shared_and_once_for_static.3F.21__I_don.27t_like_that.21

There may be a couple of syntactical issues with the writeup.

For example, you may need to have at least one source file composing the
shared library, in addition to the static libraries that you want to ad.

The -fPIC should be set in SET_TARGET_PROPERTIES and not in
ADD_LIBRARY.  I believe the example I have below to be correct, but your
mileage may vary.

Regards,

Juan

Juan Sanchez wrote:
 Two things with convenience libraries.  Part of this may be in the FAQ:
 
 On linux, compile the code fPIC or fpic (slightly different meanings).
 
 So for library hello:
 SET_TARGET_PROPERTIES(
 hello PROPERTIES
 OUTPUT_NAME hello
 CLEAN_DIRECT_OUTPUT 1
 COMPILE_FLAGS -fPIC
 )
 
 where hello is the name of your static convenience library.
 
 Make sure all symbols get put into the so:
 target_link_libraries(mywrap -Wl,-whole-archive
 hello -Wl,-no-whole-archive)
 
 where mywrap is the name of the shared library, and hello is the static
 library you want attached to it.  If you are attaching multiple
 libraries, linker order may be important.
 
 Juan
 
 
 
 Salvatore Iovene wrote:
 Hi,
 I'm not 100% sure this is really a CMake related question, but I'll
 fire it up anyway:

 I'm building a series of static libraries, name them liba.a, libb.a
 and libc.a, and linking them into a shared library libfoo.so.

 Then I'm building libx.a liby.a and libz.a and linking them into the
 shared libbar.so.

 Then I have an executable whatever.exe that's linked to to libfoo.so
 and libbar.so. The linking of the executable fails complaining of
 certain missing simbols. Some symbols from liba.a are missing in
 libbar.so.

 So far I have fixed the issue by linking one of the libs of
 libfoo.so (say libx.a) to libbar.so. But this smells of nasy
 workaround.

 Obviously I'm doing something wrong here, so could anyone please help?

 Thanks!

 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] Linking problem

[Juan Sanchez]

Two things with convenience libraries.  Part of this may be in the FAQ:

On linux, compile the code fPIC or fpic (slightly different meanings).

So for library hello:
SET_TARGET_PROPERTIES(
hello PROPERTIES
OUTPUT_NAME hello
CLEAN_DIRECT_OUTPUT 1
COMPILE_FLAGS -fPIC
)

where hello is the name of your static convenience library.

Make sure all symbols get put into the so:
target_link_libraries(mywrap -Wl,-whole-archive
hello -Wl,-no-whole-archive)

where mywrap is the name of the shared library, and hello is the static
library you want attached to it.  If you are attaching multiple
libraries, linker order may be important.

Juan



Salvatore Iovene wrote:
 Hi,
 I'm not 100% sure this is really a CMake related question, but I'll
 fire it up anyway:
 
 I'm building a series of static libraries, name them liba.a, libb.a
 and libc.a, and linking them into a shared library libfoo.so.
 
 Then I'm building libx.a liby.a and libz.a and linking them into the
 shared libbar.so.
 
 Then I have an executable whatever.exe that's linked to to libfoo.so
 and libbar.so. The linking of the executable fails complaining of
 certain missing simbols. Some symbols from liba.a are missing in
 libbar.so.
 
 So far I have fixed the issue by linking one of the libs of
 libfoo.so (say libx.a) to libbar.so. But this smells of nasy
 workaround.
 
 Obviously I'm doing something wrong here, so could anyone please help?
 
 Thanks!
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] Linking problem

[Juan Sanchez]

I believe this to be the more accurate than the FAQ and my previous
example.  In addition, the static and shared libraries can have the same
name.

Note that cat.cc is an empty file, since the linker will not work
without at least one object file on the dynamic target.

IF(CMAKE_SYSTEM_NAME STREQUAL Linux AND CMAKE_COMPILER_IS_GNUCC)
   ADD_LIBRARY(zzSTATIC STATIC dog.cc)
   ADD_LIBRARY(zzDYNAMIC SHARED cat.cc)
   TARGET_LINK_LIBRARIES(zzDYNAMIC -Wl,-whole-archive zzSTATIC
-Wl,-no-whole-archive)
   SET_TARGET_PROPERTIES(
 zzSTATIC PROPERTIES
 OUTPUT_NAME zz
 CLEAN_DIRECT_OUTPUT 1
 COMPILE_FLAGS -fPIC
   )
   SET_TARGET_PROPERTIES(
 zzDYNAMIC PROPERTIES
 OUTPUT_NAME zz
 CLEAN_DIRECT_OUTPUT 1
   )
ENDIF(CMAKE_SYSTEM_NAME STREQUAL Linux AND CMAKE_COMPILER_IS_GNUCC)

Regards,

Juan

Juan Sanchez wrote:
 Hello,
 
 There a much nicer platform independent writeup on this at:
 
 http://www.cmake.org/Wiki/CMake_FAQ#Does_that_mean_I_have_to_build_all_my_library_objects_twice.2C_once_for_shared_and_once_for_static.3F.21__I_don.27t_like_that.21
 
 There may be a couple of syntactical issues with the writeup.
 
 For example, you may need to have at least one source file composing the
 shared library, in addition to the static libraries that you want to ad.
 
 The -fPIC should be set in SET_TARGET_PROPERTIES and not in
 ADD_LIBRARY.  I believe the example I have below to be correct, but your
 mileage may vary.
 
 Regards,
 
 Juan
 
 Juan Sanchez wrote:
 Two things with convenience libraries.  Part of this may be in the FAQ:

 On linux, compile the code fPIC or fpic (slightly different meanings).

 So for library hello:
 SET_TARGET_PROPERTIES(
 hello PROPERTIES
 OUTPUT_NAME hello
 CLEAN_DIRECT_OUTPUT 1
 COMPILE_FLAGS -fPIC
 )

 where hello is the name of your static convenience library.

 Make sure all symbols get put into the so:
 target_link_libraries(mywrap -Wl,-whole-archive
 hello -Wl,-no-whole-archive)

 where mywrap is the name of the shared library, and hello is the static
 library you want attached to it.  If you are attaching multiple
 libraries, linker order may be important.

 Juan



 Salvatore Iovene wrote:
 Hi,
 I'm not 100% sure this is really a CMake related question, but I'll
 fire it up anyway:

 I'm building a series of static libraries, name them liba.a, libb.a
 and libc.a, and linking them into a shared library libfoo.so.

 Then I'm building libx.a liby.a and libz.a and linking them into the
 shared libbar.so.

 Then I have an executable whatever.exe that's linked to to libfoo.so
 and libbar.so. The linking of the executable fails complaining of
 certain missing simbols. Some symbols from liba.a are missing in
 libbar.so.

 So far I have fixed the issue by linking one of the libs of
 libfoo.so (say libx.a) to libbar.so. But this smells of nasy
 workaround.

 Obviously I'm doing something wrong here, so could anyone please help?

 Thanks!


 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] improve the CMake language?

[Juan Sanchez]

I was reading exactly the link you sent, and the same one you accused
Brandon of not reading.  If there were supplemental materials, you
should have sent them.  I am not a lawyer.

To be honest, the only compelling languages I've seen so far in this
discussion is lua and tcl.  This is because they are small and appear to
be ideal for embedding.

Not that speed is super important, but I know of at least one hosting
provider making exceptions for ruby scripts, because they just take way
too long to run.

Juan

Gonzalo Garramuño wrote:
 Sanchez, Juan wrote:
 This part of the license would concern me.  Are all files of interest, 
 by other authors, guaranteed to be BSD friendly?

 
 
 Again, read LEGAL.  You will then find that:
 
 regex when used with Ruby it is Ruby licensed, based on Onigurama.
 utils is BSD, credit going to Lucent Technologies.
 gcis Public Domain (Boehmm), albeit now is so heavily modified 
 there's no resemblance to it any longer (probably the docs need updating).
 stis Public Domain.
 
 Other files may use Perl's Artistic License.
 
 


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

Re: [CMake] compiler major, minor version

[Juan Sanchez]

Please see:

http://predef.sourceforge.net/precomp.html

for an interesting compiler version reference page.

Juan


Brandon Van Every wrote:
 Is there any canonical way to extract the compiler's major and minor
 version numbers?  I can do this with regexes, but as CMake moves into
 cross-compilation territory, it seems like it would be a typical
 operation and possibly canonized already.  If not then perhaps it
 should be, i.e. a feature request.  Thoughts?
 
 
 Cheers,
 Brandon Van Every
 ___
 CMake mailing list
 CMake@cmake.org
 http://www.cmake.org/mailman/listinfo/cmake
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] improve the CMake language?

[Juan Sanchez]

Brandon Van Every wrote:
 On Nov 2, 2007 11:49 AM, Juan E. Sanchez [EMAIL PROTECTED] wrote:
 On Fri, 2 Nov 2007, Brandon Van Every wrote:
 To make real improvements in all of those areas, you'd need a lot of
 funding.  What kind of mandate do you have?  There's not much point in
 saying everything's gonna be better if you don't have the labor.
 This would be a community effort.  I don't have the resources to
 strike out on my own.
 
 Without a bunch of gold bars at your disposal, I'd say the CMake
 community isn't going anywhere.  Best to work on compromises within
 the community rather than sweeping changes.
 
 I like using cmake.  The language is kind of a
 bitter pill for people in my organization to swallow.

 The most important item on my proposed feature list is the Tcl
 frontend.
 
 I know everyone champions their favorite scripting language, but my
 opinion is, if you go that route you're doomed.  Pick something that
 programmers consider modern and sexy, or you're never going to get the
 mindshare.  A key consideration that dominates my own thinking as of
 late: Who's gonna pay me to know language X ?  I went back to C++
 for this reason.  I'm sorry but whatever its merits, Tcl is not a
 resume skill nowadays.

Actually Tcl is still quite popular.  Many commercial electronic design
automation (EDA) companies use Tcl frontends, and EDA is a billion
dollar industry.  Active State still seems to be doing well peddling
their supported versions of Tcl as well.

Apart from its consistent syntax, another big selling point is its truly
free license.

I'd be willing to entertain any other suggestions for scripting
languages, as long as:
1. the syntax is consistent
2. the language is not bloated
3. the language does not require to much dressing up with parenthesis
and commas
4. the license is BSD-like in nature.

Note that OOP is more of a detriment than a benefit in my concept of
simple scripting languages.  Obfuscation by encapsulation is not a
benefit in a flat file architecture.

Regards,

Jun


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

Re: [CMake] lexical scoping

[Juan Sanchez]

My suggestion as a temporary work around would be to apply a namespace
prefix to the variables in your macro.

Create the macro with short variable names x.
Test
Replace variable names with uniques ones MACRO_DOIT_x
Release

If included in another file, your users don't have to see the munged
code underneath.

Juan

Brandon Van Every wrote:
 On Nov 2, 2007 4:13 PM, Bill Hoffman [EMAIL PROTECTED] wrote:
 Brandon Van Every wrote:
 On Nov 2, 2007 3:44 PM, Bill Hoffman [EMAIL PROTECTED] wrote:
 I have an idea.  What if we created a variable_scope command?
 Bad markerting idea.  Nobody programs in this idiom.  (Well, I don't
 know about Perl, as far as I'm concerned they're nobody.  ;-)  Lotsa
 people program with functions and would expect a scripting language to
 have functions.  Minimize the number of CMake specific weird things
 people have to learn, if you want more users.  SETLOCAL is not so
 objectionable, didn't some Unix shells have this historically?

 The problem is what does SETLOCAL mean?   There is no scope in cmake
 right now.  So, I guess you are saying add functions.
 
 Yep.
 
 I am not even
 sure what those will be...  Many languages have the idea of scope.
 Braces in C++.   This would just be a way of creating scope.
 
 Then add braces.  Not some begin_long_thing_word end_long_thing_word.
 Nobody does that, nobody will like it.
 
 
 Cheers,
 Brandon Van Every
 ___
 CMake mailing list
 CMake@cmake.org
 http://www.cmake.org/mailman/listinfo/cmake
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] lexical scoping

[Juan Sanchez]

Oh,

I guess you did.  My apologies.

I guess the best way to fix your issue would be to move to a lua frontend.

Juan

Brandon Van Every wrote:
 On Nov 2, 2007 4:22 PM, Juan Sanchez [EMAIL PROTECTED] wrote:
 My suggestion as a temporary work around would be to apply a namespace
 prefix to the variables in your macro.
 
 That's what my example is.  I even pointed out the naming policy I
 use.  I want to talk about making things better, not how to work
 around the issue at present.  I already know how to do that, and the
 point is, it's a PITA.  The more PITA in CMake, the slower the
 adoption rate.
 
 
 Cheers,
 Brandon Van Every


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

Re: [CMake] wxCmakeSetup

[Juan Sanchez]

Where is the source for wxCMakeSetup?

What platforms do you need it to compile for?  I could do linux and
maybe cygwin.

Juan

Mike Jackson wrote:
 I am more intersted in a nice Qt CMakeSetup but with some more added  
 features. wxWidgets and Fltk just do not look that good under OS X. I  
 am also hoping that if a nice Qt GUI were made Kitware might include  
 it since ParaView uses Qt. It would make a nice standardization on  
 Qt, which is a nice toolkit.
 
 I would write the Qt if I new what to actually implement. Not being  
 able to compile the wx version leaves me with no real working code to  
 look at.  I guess a little hand holding or this is where to look or  
 you need to implement these functions would be a nice start.. hint  
 hint..
 



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

Re: [CMake] wxCmakeSetup

[Juan Sanchez]

With wxWidgets 2.6.8, the 64 bit issues appear to be solved.
Unfortunately, it no longer likes receiving (const char *)'s without
converting them using some special functions.  It would take a while to
change the code according to the instructions in:
http://www.wxwidgets.org/wiki/index.php/WxString

namely (const char []) would have to be placed in a _T().
wxString string(_T(Some text));

and (const char *) would have have to have something like:

const char *ascii_str = Some text;
wxString string(ascii_str, wxConvUTF8);

Not a trivial task.

Juan

Bill Hoffman wrote:
 Mike Jackson wrote:
 I am more intersted in a nice Qt CMakeSetup but with some more added 
 features. wxWidgets and Fltk just do not look that good under OS X. I am 
 also hoping that if a nice Qt GUI were made Kitware might include it 
 since ParaView uses Qt. It would make a nice standardization on Qt, 
 which is a nice toolkit.

 I would write the Qt if I new what to actually implement. Not being able 
 to compile the wx version leaves me with no real working code to look 
 at.  I guess a little hand holding or this is where to look or you 
 need to implement these functions would be a nice start.. hint hint..

 
 Sounds like 2.6.2 wxwidgets should work.
 
 
 There are code examples for cmake gui's in the cmake source tree. 
 ccmake, CMakeSetup, and wxCMakeSetup.   The MFC one is not a bad place 
 to start.   Most of the work is done in a cmake object.   The basic gui 
 does this:
 
 1. load registry stuff from previous runs
 
 2. configure
 - ask for a generator to use if one is not yet set
 - ask to create build directory if not there
 - save the gui values to the cache file
 - call cmake::Configure()
 - save stuff to registry
 
 3. Generate
  - only allowed to do this if configure has been run and there are 
 no new cache values or errors.
  - call cmake::Generate()
  - save stuff to the registry
 
 The big part of the implementation is the save/load of the cache.  You 
 don't actually have to save the cache, you just have to set values in 
 the cache and call save on it.  You can find that code here:
 
 // copy from the cache manager to the cache edit list box
 void CMakeSetupDialog::FillCacheGUIFromCacheManager()
 // copy from the list box to the cache manager
 void CMakeSetupDialog::FillCacheManagerFromCacheGUI()
 
 CMakeSetupDialog::FillCacheGUIFromCacheManager
 
 
 -Bill
 
 ___
 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] Wrong number of ../ elements in target path? 2.4.6 vs. 2.4.7 bug?

[Juan Sanchez]

Hi Christian,

Have you considered using full paths, such as
${PROJECT_SOURCE_DIR}
and
${PROJECT_BINARY_DIR}

Juan

Christian Convey wrote:
 OK, I've figured it out.  Consider the following code.  I use it to
 decide, at cmake time, what subdirectories will be built in the
 project (trust me - I have a reason to do it this way.)
 
 Anyway, if a subdirectory (or descendant of a subdirectory) has a file
 named ExtraCMakeIncludeDirs.txt, then the directory containing that
 file will later be added to the build using the ADD_SUBDIRECTORY()
 command:
 
 FILE(GLOB_RECURSE CUSTOM_ADDED_INCLUDES ./ExtraCMakeIncludeDirs.txt)
 FOREACH(F ${CUSTOM_ADDED_INCLUDES})
   INCLUDE(${F})
   GET_FILENAME_COMPONENT(DIR ${F} PATH)
   MESSAGE(Adding supplemental source directory:  ${DIR})
   SET(IVP_DIRS_TO_BUILD ${IVP_DIRS_TO_BUILD} ${DIR})
 ENDFOREACH(F)
 
 The problem comes from the ./ on the first line of that code shown
 above.  This results in an extra ./ appearing in the middle of the
 pathnames emitted by the FILE(GLOB_RECUSE ...) command.
 
 Somehow, CMake 2.4.6 gets thrown off track by that semantically
 meaningless part of the  pathname.  My guess is that when the Unix
 makefile generator is calculating the relative pathname to supply the
 linker, its calculations get thrown off by the presence of /./
 inside the path.
 
 Anyway, for 2.4.6, I fixed this in my CMakeLists.txt file by simply
 replacing ./ExtraCMakeIncludeDirs.txt with
 ExtraCMakeIncludeDirs.txt.  And as I mentioned earlier, for some
 reason this seems to just be a non-issue in 2.4.7.
 
 Thanks everyone for the help.
 
 - Christian
 ___
 CMake mailing list
 CMake@cmake.org
 http://www.cmake.org/mailman/listinfo/cmake
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

[CMake] compare ctest to dejagnu?

[Juan Sanchez]

Someone in my group is investigating dejagnu.  I was wondering if anyone
with experience in ctest and dejagnu has any thoughts on these two
testing systems?

Thanks,

Juan


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

Re: [CMake] purify targets

[Juan Sanchez]

To clarify my question, should I expect changing
CMAKE_CXX_LINK_EXECUTABLE to apply to both targets in the example below?

This is cmake 2.4.7.

Regards,

Juan

Juan Sanchez wrote:
 Hello,
 
 Is it possible to build both purify and non purify targets by changing
 CMAKE_CXX_LINK_EXECUTABLE?  Unfortunately the following example purify's
 both binaries.
 
 ADD_EXECUTABLE(hello helloworld.cc)
 SET (CMAKE_CXX_LINK_EXECUTABLE purify -cache-dir=/tmp
 ${CMAKE_CXX_LINK_EXECUTABLE})
 ADD_EXECUTABLE(hello.purify helloworld.cc)
 
 Thanks,
 
 Juan


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

[CMake] purify targets

[Juan Sanchez]

Hello,

Is it possible to build both purify and non purify targets by changing
CMAKE_CXX_LINK_EXECUTABLE?  Unfortunately the following example purify's
both binaries.

ADD_EXECUTABLE(hello helloworld.cc)
SET (CMAKE_CXX_LINK_EXECUTABLE purify -cache-dir=/tmp
${CMAKE_CXX_LINK_EXECUTABLE})
ADD_EXECUTABLE(hello.purify helloworld.cc)

Thanks,

Juan


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

[CMake] for install before running tests

[Juan Sanchez]

The test scripts for an existing project rely greatly on the installed
directory structure.  Is it possible to always force an install before
the tests are run?

Thanks,

Juan
-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

[CMake] get the target name in add_custom_command

[Juan Sanchez]

In this example, the target name foo has a different OUTPUT_NAME.  How
do I tell ADD_CUSTOM_COMMAND to use the real name of the target when I
try to use the copy command within?

ADD_CUSTOM_COMMAND(TARGET foo POST_BUILD COMMAND ${CMAKE_COMMAND} -E
copy foo ${PROJECT_SOURCE_DIR}/${INSTALL_DIR})

Thanks,

Juan



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

Re: [CMake] for install before running tests

[Juan Sanchez]

Thanks for your response.  Unfortunately, I don't have control over the
original script to be run.  Creating a similar script creates a forking
issue, where I am always 2 steps behind the people updating the original
script.

The install target is meant to copy the files into the original source
tree, with specific directories for each build type.  The regression
script is keyed into this directory structure.

Is there a way to force the install target as a default build?

Perhaps it'd be best for me to create a POST_BUILD ADD_CUSTOM_COMMAND,
which will put a copy of the binary and libraries in the correct place?

Regards,

Juan

Alan W. Irwin wrote:
 On 2007-10-09 10:12-0500 Juan Sanchez wrote:
 
 The test scripts for an existing project rely greatly on the installed
 directory structure.
 
 For your information, that's contrary to the fundamental idea behind ctest
 (and autotools make check as well) which is that all tests are run in the
 build tree (i.e., potentially before make install is run).
 
 For the PLplot case we had a test script that was originally designed to
 work just for the install-tree case, but back in our autotools days we
 modified that script to have an option to work in the build-tree case to
 deal with the make check autotools case.  That option continued to be
 implemented as part of our later CMake-based build system. For that case,
 when the build-tree option is on, the test script depends strictly on build
 tree executables, libraries, shell scripts, and data files rather than their
 installed counterparts, and the test script is run indirectly by ctest
 from the build tree.
 
 The approach of having a test script with build-tree and install-tree
 options gives us the best of both worlds.
 
 (1) A comprehensive install-tree test (run from the install tree by merely
 executing the test script) for those who install PLplot (including end users
 of PLplot who tend to install it in binary form only).
 
 (2) A virtually identical build-tree test run by ctest for those who build
 PLplot. The latter is especially useful to our developers to check the
 recent changes they have made.  In the future we also plan to take the next
 obvious step with our testing which is to use ctest for nightly automated
 testing of our svn repository with results collected by a dartboard server.
 
 I suggest a similar approach where you modify your install-tree only script
 to have a build-tree option as well would be well worth your while.
 
 Alan
 __
 Alan W. Irwin
 
 Astronomical research affiliation with Department of Physics and Astronomy,
 University of Victoria (astrowww.phys.uvic.ca).
 
 Programming affiliations with the FreeEOS equation-of-state implementation
 for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
 package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
 Linux Links project (loll.sf.net); and the Linux Brochure Project
 (lbproject.sf.net).
 __
 
 Linux-powered Science
 __
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

[CMake] cmake copy command problem

[Juan Sanchez]

Since I must copy a target after it's built, I synthesize a compile time
install command.

Unfortunately, the copy command obliterates the destination directory
with a copy of the file being created.

This seems to be contrary to the cmake -E help documentation:
copy file destination   - copy file to destination (either file or
directory)

Am I somehow using the make_directory and copy commands incorrectly?  My
code is below.

Thanks,

Juan

GET_TARGET_PROPERTY(LOC foo LOCATION)
ADD_CUSTOM_COMMAND(TARGET foo POST_BUILD
COMMAND ${CMAKE_COMMAND} -E make_directory
${PROJECT_SOURCE_DIR}/${INSTALL_DIR}
COMMAND ${CMAKE_COMMAND} -E copy ${LOC} ${PROJECT_SOURCE_DIR}/${INSTALL_DIR}
)



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

Re: [CMake] cmake copy command problem

[Juan Sanchez]

I apologize.  Upon further testing, this doesn't appear to be an issue.

Thanks,

Juan

Juan Sanchez wrote:
 Since I must copy a target after it's built, I synthesize a compile time
 install command.
 
 Unfortunately, the copy command obliterates the destination directory
 with a copy of the file being created.
 
 This seems to be contrary to the cmake -E help documentation:
 copy file destination   - copy file to destination (either file or
 directory)
 
 Am I somehow using the make_directory and copy commands incorrectly?  My
 code is below.
 
 Thanks,
 
 Juan
 
 GET_TARGET_PROPERTY(LOC foo LOCATION)
 ADD_CUSTOM_COMMAND(TARGET foo POST_BUILD
 COMMAND ${CMAKE_COMMAND} -E make_directory
 ${PROJECT_SOURCE_DIR}/${INSTALL_DIR}
 COMMAND ${CMAKE_COMMAND} -E copy ${LOC} ${PROJECT_SOURCE_DIR}/${INSTALL_DIR}
 )
 
 
 
 ___
 CMake mailing list
 CMake@cmake.org
 http://www.cmake.org/mailman/listinfo/cmake
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] Version embedding - how to cause a command when make is run?

[Juan Sanchez]

How about:

 svn info file:///home/juans/svn_repository/svnroot/ | grep '^Revision:'
| sed -e 's/^[^0-9]*//'

on the repository.

Or just:

 svn info | grep '^Revision:' | sed -e 's/^[^0-9]*//'

After doing a svn update, the latest revision on the url seems to be
accurate.  Unfortunately the number seems to apply to the whole
repository.  I guess it's a good way to make sure you are up to date.

svnlook youngest seems to do something, but it appears to only work on
the same filesystem as the repository.


Regards,

Juan

David Cole wrote:
 How about svn status -u or a filtered version of svn status -v ?
 
 On 10/5/07, Atwood, Robert C [EMAIL PROTECTED] wrote:
 I hope its okay to copy this to Subversion list, as it has veered away
 from cmake  ...

 Alan said (on Cmake list):

 take a concrete but simple example, suppose you have five
 files which all
 have 3 possibilities (1,2,3) for the revision number. IOW,
 each file changed
 for each revision. Then using svn update --revision you can
 create 3^5 = 243
 different combinations of revision numbers for the various
 source files in
 your source tree, and svnversion will identify all such
 different source
 trees identically.
 I expected that sort of thing with CVS, I thought it worked differently
 in SVN where the number is more related to the whole project than the
 individual file. But I stand corrected.

 An actual test demonstrates that you are correct, svnversion 0:6 is
 displayed if one of the files is back-updated to 4, and no special flag
 is specified in svnversion output. See console log below.


 David said (on Cmake list):

 also verify that svn status gives you *empty*
 output.
 Actually ,   'svn status' also produces empty output in this case (where
 a file has been back-updated)  So it is not obvious that there's any
 difference, as Alan suggested orignally.

 Thanks for the headsup!
 Robert


 [rcatwood testproj]$ svnversion
 0:6
 [rcatwood testproj]$ cat *
 $Id: FileA.txt 6 2007-10-05 15:50:26Z rcatwood $
 This is file A. Third (after propset) revision.
 $Id: FileB.txt 6 2007-10-05 15:50:26Z rcatwood $
 This is file B. Third (after propset) revision.
 $Id: FileC.txt 6 2007-10-05 15:50:26Z rcatwood $
 This is file C. Third (after propset) revision.
 $Id: FileD.txt 6 2007-10-05 15:50:26Z rcatwood $
 This is file D. Third (after propset) revision.
 $Id: FileE.txt 6 2007-10-05 15:50:26Z rcatwood $
 This is file E. Third (after propset) revision.
 [rcatwood testproj]$
 [rcatwood testproj]$ svn up -r 4 FileC.txt
 UFileC.txt
 Updated to revision 4.
 [rcatwood testproj]$ svnversion
 0:6
 [rcatwood testproj]$ cat *
 $Id: FileA.txt 6 2007-10-05 15:50:26Z rcatwood $
 This is file A. Third (after propset) revision.
 $Id: FileB.txt 6 2007-10-05 15:50:26Z rcatwood $
 This is file B. Third (after propset) revision.
 $Id: FileC.txt 4 2007-10-05 15:49:14Z rcatwood $
 This is file C. First (after propset) revision.
 $Id: FileD.txt 6 2007-10-05 15:50:26Z rcatwood $
 This is file D. Third (after propset) revision.
 $Id: FileE.txt 6 2007-10-05 15:50:26Z rcatwood $
 This is file E. Third (after propset) revision.
 [rcatwood testproj]$
 [rcatwood testproj]$ svn status
 [rcatwood testproj]$
 ___
 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
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] Version embedding - how to cause a command when make is run?

[Juan Sanchez]

Not being a member of the subversion list.  And doubting that non cmake
members can email this list.  Please email us the results of your query
to the subversion list.

Juan

David Cole wrote:
 Looks to me like the output of svn status -u will give you something like...
 Status against revision:   1234
 ... when everything is up to date with respect to svn info.
 
 And it will give something like...
  *1001   FileAtPrevRevision.cxx
 Status against revision:   1234
 ... when there is a file stuck at a previous revision.
 
 So... revising my original statement slightly:
 If the output of svn status -u is a single line matching ^Status
 against revision: then you can trust the output of svn info as
 meaning : this is a build against this revision without any known
 deviations from the revision.
 
 Svn list : correct me if I'm wrong. :-)
 
 
 HTH,
 David
 
 
 On 10/5/07, David Cole [EMAIL PROTECTED] wrote:
 How about svn status -u or a filtered version of svn status -v ?

 On 10/5/07, Atwood, Robert C [EMAIL PROTECTED] wrote:
 I hope its okay to copy this to Subversion list, as it has veered away
 from cmake  ...

 Alan said (on Cmake list):

 take a concrete but simple example, suppose you have five
 files which all
 have 3 possibilities (1,2,3) for the revision number. IOW,
 each file changed
 for each revision. Then using svn update --revision you can
 create 3^5 = 243
 different combinations of revision numbers for the various
 source files in
 your source tree, and svnversion will identify all such
 different source
 trees identically.
 I expected that sort of thing with CVS, I thought it worked differently
 in SVN where the number is more related to the whole project than the
 individual file. But I stand corrected.

 An actual test demonstrates that you are correct, svnversion 0:6 is
 displayed if one of the files is back-updated to 4, and no special flag
 is specified in svnversion output. See console log below.


 David said (on Cmake list):

 also verify that svn status gives you *empty*
 output.
 Actually ,   'svn status' also produces empty output in this case (where
 a file has been back-updated)  So it is not obvious that there's any
 difference, as Alan suggested orignally.

 Thanks for the headsup!
 Robert


 [rcatwood testproj]$ svnversion
 0:6
 [rcatwood testproj]$ cat *
 $Id: FileA.txt 6 2007-10-05 15:50:26Z rcatwood $
 This is file A. Third (after propset) revision.
 $Id: FileB.txt 6 2007-10-05 15:50:26Z rcatwood $
 This is file B. Third (after propset) revision.
 $Id: FileC.txt 6 2007-10-05 15:50:26Z rcatwood $
 This is file C. Third (after propset) revision.
 $Id: FileD.txt 6 2007-10-05 15:50:26Z rcatwood $
 This is file D. Third (after propset) revision.
 $Id: FileE.txt 6 2007-10-05 15:50:26Z rcatwood $
 This is file E. Third (after propset) revision.
 [rcatwood testproj]$
 [rcatwood testproj]$ svn up -r 4 FileC.txt
 UFileC.txt
 Updated to revision 4.
 [rcatwood testproj]$ svnversion
 0:6
 [rcatwood testproj]$ cat *
 $Id: FileA.txt 6 2007-10-05 15:50:26Z rcatwood $
 This is file A. Third (after propset) revision.
 $Id: FileB.txt 6 2007-10-05 15:50:26Z rcatwood $
 This is file B. Third (after propset) revision.
 $Id: FileC.txt 4 2007-10-05 15:49:14Z rcatwood $
 This is file C. First (after propset) revision.
 $Id: FileD.txt 6 2007-10-05 15:50:26Z rcatwood $
 This is file D. Third (after propset) revision.
 $Id: FileE.txt 6 2007-10-05 15:50:26Z rcatwood $
 This is file E. Third (after propset) revision.
 [rcatwood testproj]$
 [rcatwood testproj]$ svn status
 [rcatwood testproj]$
 ___
 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
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

[CMake] install before test

[Juan Sanchez]

How can you ensure that an install has done before you attempt to run
the tests?

Thanks,

Juan

-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

[CMake] ctest command

[Juan Sanchez]

Hi,

I'm trying to run the following test:
ADD_TEST(foo ${CMAKE_TEST_COMMAND} --build-run-dir
${PROJECT_SOURCE_DIR} -VV --test-command ls -ltar /tmp)

But it doesn't seem to be running correctly.  It needs to be run from
${PROJECT_SOURCE_DIR}, and the test command needs to be able to take the
arguments given.

Please let me know what I need to do to get this to run.

Testing/Temporary/LastTest.log

always appears to be empty and the -VV option does not work.

This is cmake 2.4.7.

Thanks,

Juan


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] Dealing with circular linker dependencies

[Juan Sanchez]

Aside from rearchitecting your project.  You need to place one library
on both sides of the other library in the arguments to the linker.

-l A -l B -l A

This assures that the linker can resolve all the needed symbols.

Juan

Tal Blum wrote:
 I have two c++ libraries each depending on the other which creates a
 circular linker dependency problem. Does anyone know how to solve this
 problem? If this is not possible to solve at the command-line level can
 someone tell me how I can write a ADD_CUSTOM_COMMAND or
 ADD_CUSTOM_TARGET that will collect all the object files into a new
 library and make my executable depend on that new library target.
 
  
 
 Thanks, Tal
 
  
 
 
 
 
 ___
 CMake mailing list
 CMake@cmake.org
 http://www.cmake.org/mailman/listinfo/cmake


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] ctest command

[Juan Sanchez]

I am trying to follow an example that is in the cmake book.  It is in
section 8.5 Using CTest to Drive Complex Tests on page 109.  While my
example differs in that it doesn't use all the arguments being used in
the book's example, it is very important that I understand how to do this.

My primary motivation was getting the -V or -VV option passed to the
test in order that cmake doesn't void the output from the test, but now
I just want to understand what it takes to get CMAKE_CTEST_COMMAND to
work inside the ADD_TEST statement.

Regards,

Juan




Alan W. Irwin wrote:
 On 2007-10-04 13:03-0500 Juan Sanchez wrote:
 
 Hi,

 I'm trying to run the following test:
 ADD_TEST(foo ${CMAKE_TEST_COMMAND} --build-run-dir
 ${PROJECT_SOURCE_DIR} -VV --test-command ls -ltar /tmp)

 But it doesn't seem to be running correctly.  It needs to be run from
 ${PROJECT_SOURCE_DIR}, and the test command needs to be able to take the
 arguments given.
 
 I don't have practical experience with many of these ctest options, but I
 was curious and looked them up in the documentation, and it appears you are
 not using them correctly.  For example, --test-command is documented (by
 ctest --help-full) as
 
 The test to run with the --build-and-test option.
 
 but you don't have a --build-and-test option above so I think that's why
 your --test-command option is being ignored.
 
 Also, I am curious about your practical goal.  If/when the above test
 works it looks like it would create a a simple test that would allow ctest
 to invoke ctest on the command line. Do you need that extra level of ctest
 indirection?
 
 An alternative to the above extra layer of ctest indirection is to write a
 configurable bash or python or perl script to do what you want at ctest time
 and set up ctest for it using
 
 ADD_TEST(foo full_path/scriptname).
 
 The configurable script, of course, allows you to change directories to any
 configured directory before you run your actual test.
 
 Alan
 __
 Alan W. Irwin
 
 Astronomical research affiliation with Department of Physics and Astronomy,
 University of Victoria (astrowww.phys.uvic.ca).
 
 Programming affiliations with the FreeEOS equation-of-state implementation
 for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
 package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
 Linux Links project (loll.sf.net); and the Linux Brochure Project
 (lbproject.sf.net).
 __
 
 Linux-powered Science
 __
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

solved! Re: [CMake] ctest command

[Juan Sanchez]

To solve my issue, I only need to specify the following.  Otherwise, no
error is printed, the test will always past, and ctest --debug prints
pages and pages of debug info.

ENABLE_TESTING()
ADD_TEST(foo  ${CMAKE_CTEST_COMMAND} --build-and-test
${PROJECT_SOURCE_DIR} ${PROJECT_BINARY_DIR} --build-generator
${CMAKE_GENERATOR}  --build-makeprogram ${CMAKE_MAKE_PROGRAM}
--build-nocmake --build-run-dir ${PROJECT_SOURCE_DIR} -VV --test-command
/bin/ls)


Primary goals:
1. Run regression script which must be run from PROJECT_SOURCE_DIR.
2. Verbose output from the script being run

Thanks,

Juan


Juan Sanchez wrote:
 I am trying to follow an example that is in the cmake book.  It is in
 section 8.5 Using CTest to Drive Complex Tests on page 109.  While my
 example differs in that it doesn't use all the arguments being used in
 the book's example, it is very important that I understand how to do this.
 
 My primary motivation was getting the -V or -VV option passed to the
 test in order that cmake doesn't void the output from the test, but now
 I just want to understand what it takes to get CMAKE_CTEST_COMMAND to
 work inside the ADD_TEST statement.
 
 Regards,
 
 Juan
 
 
 
 
 Alan W. Irwin wrote:
 On 2007-10-04 13:03-0500 Juan Sanchez wrote:

 Hi,

 I'm trying to run the following test:
 ADD_TEST(foo ${CMAKE_TEST_COMMAND} --build-run-dir
 ${PROJECT_SOURCE_DIR} -VV --test-command ls -ltar /tmp)

 But it doesn't seem to be running correctly.  It needs to be run from
 ${PROJECT_SOURCE_DIR}, and the test command needs to be able to take the
 arguments given.
 I don't have practical experience with many of these ctest options, but I
 was curious and looked them up in the documentation, and it appears you are
 not using them correctly.  For example, --test-command is documented (by
 ctest --help-full) as

 The test to run with the --build-and-test option.

 but you don't have a --build-and-test option above so I think that's why
 your --test-command option is being ignored.

 Also, I am curious about your practical goal.  If/when the above test
 works it looks like it would create a a simple test that would allow ctest
 to invoke ctest on the command line. Do you need that extra level of ctest
 indirection?

 An alternative to the above extra layer of ctest indirection is to write a
 configurable bash or python or perl script to do what you want at ctest time
 and set up ctest for it using

 ADD_TEST(foo full_path/scriptname).

 The configurable script, of course, allows you to change directories to any
 configured directory before you run your actual test.

 Alan
 __
 Alan W. Irwin

 Astronomical research affiliation with Department of Physics and Astronomy,
 University of Victoria (astrowww.phys.uvic.ca).

 Programming affiliations with the FreeEOS equation-of-state implementation
 for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
 package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
 Linux Links project (loll.sf.net); and the Linux Brochure Project
 (lbproject.sf.net).
 __

 Linux-powered Science
 __


 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

unsolved! Re: solved! Re: [CMake] ctest command

[Juan Sanchez]

I'll just have to go back to the wrapper script.  I can't figure out why
 running make test can no trigger a rebuild.  Also, --build-noclean
does not help.

Is there any natural way to get verbose output to the screen from an
executable being run by ctest?  Aside from a wrapper script, is there
any way to tell ctest to run in a specific directory?

Thanks,

Juan

Juan Sanchez wrote:
 To solve my issue, I only need to specify the following.  Otherwise, no
 error is printed, the test will always past, and ctest --debug prints
 pages and pages of debug info.
 
 ENABLE_TESTING()
 ADD_TEST(foo  ${CMAKE_CTEST_COMMAND} --build-and-test
 ${PROJECT_SOURCE_DIR} ${PROJECT_BINARY_DIR} --build-generator
 ${CMAKE_GENERATOR}  --build-makeprogram ${CMAKE_MAKE_PROGRAM}
 --build-nocmake --build-run-dir ${PROJECT_SOURCE_DIR} -VV --test-command
 /bin/ls)
 
 
 Primary goals:
 1. Run regression script which must be run from PROJECT_SOURCE_DIR.
 2. Verbose output from the script being run
 
 Thanks,
 
 Juan
 
 
 Juan Sanchez wrote:
 I am trying to follow an example that is in the cmake book.  It is in
 section 8.5 Using CTest to Drive Complex Tests on page 109.  While my
 example differs in that it doesn't use all the arguments being used in
 the book's example, it is very important that I understand how to do this.

 My primary motivation was getting the -V or -VV option passed to the
 test in order that cmake doesn't void the output from the test, but now
 I just want to understand what it takes to get CMAKE_CTEST_COMMAND to
 work inside the ADD_TEST statement.

 Regards,

 Juan




 Alan W. Irwin wrote:
 On 2007-10-04 13:03-0500 Juan Sanchez wrote:

 Hi,

 I'm trying to run the following test:
 ADD_TEST(foo ${CMAKE_TEST_COMMAND} --build-run-dir
 ${PROJECT_SOURCE_DIR} -VV --test-command ls -ltar /tmp)

 But it doesn't seem to be running correctly.  It needs to be run from
 ${PROJECT_SOURCE_DIR}, and the test command needs to be able to take the
 arguments given.
 I don't have practical experience with many of these ctest options, but I
 was curious and looked them up in the documentation, and it appears you are
 not using them correctly.  For example, --test-command is documented (by
 ctest --help-full) as

 The test to run with the --build-and-test option.

 but you don't have a --build-and-test option above so I think that's why
 your --test-command option is being ignored.

 Also, I am curious about your practical goal.  If/when the above test
 works it looks like it would create a a simple test that would allow ctest
 to invoke ctest on the command line. Do you need that extra level of ctest
 indirection?

 An alternative to the above extra layer of ctest indirection is to write a
 configurable bash or python or perl script to do what you want at ctest time
 and set up ctest for it using

 ADD_TEST(foo full_path/scriptname).

 The configurable script, of course, allows you to change directories to any
 configured directory before you run your actual test.

 Alan
 __
 Alan W. Irwin

 Astronomical research affiliation with Department of Physics and Astronomy,
 University of Victoria (astrowww.phys.uvic.ca).

 Programming affiliations with the FreeEOS equation-of-state implementation
 for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
 package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
 Linux Links project (loll.sf.net); and the Linux Brochure Project
 (lbproject.sf.net).
 __

 Linux-powered Science
 __



 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

[CMake] ADD_CUSTOM_COMMAND and working directory

[Juan Sanchez]

If I have multiple commands in ADD_CUSTOM_COMMAND, the WORKING_DIRECTORY
specifier seems to be ignored?

What is the proper syntax for having different working directories?

ADD_CUSTOM_COMMAND(
  OUTPUT bar
  COMMAND echo `pwd`
  WORKING_DIRECTORY ${PROJECT_SOURCE_DIR}
  COMMAND echo `pwd`
  WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
  COMMAND echo `pwd`
  WORKING_DIRECTORY ${PROJECT_SOURCE_DIR}
)


ADD_CUSTOM_TARGET( zed ALL DEPENDS bar)

Will always print the source directory.

Thanks,

Juan


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] Can Make help be set less verbose?

[Juan Sanchez]

Hi Robert,

I had no idea those targets existed.  I would find them useful,
especially if the .o files went to a deterministic location.

How about doing this?
make help | grep -v '\.[sio]$'

So that you only see your desired targets.

Juan

Bill Hoffman wrote:
 Atwood, Robert C wrote:
 Hi,
 I have a project with lots of c files that I am trying to place under
 Cmake. And, I must say , it is working really well ! But ... Since there
 are lots of c files, the list of possible targets returned by
 'make help', after running cmake, is rather useless (unless run though
 'head -8' or 'more')
 Is there an option somewhere to suppress inclusion of all the single
 file targets (.o, .i, .s ) in the 'make help' output? Nobody really
 wants to know about those ... do they ;-? 
   
 Maybe we need a make helpless  :-)
 
 You could add a feature request to the bug tracker.  
 
 -Bill
 
 ___
 CMake mailing list
 CMake@cmake.org
 http://www.cmake.org/mailman/listinfo/cmake
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

[CMake] SET_TARGET_PROPERTIES twice

[Juan Sanchez]

I just discovered that the moment I add a second SET_TARGET_PROPERTIES
statement for a specific target, cmake will implicitly fail, and not
write out a Makefile.  It even states that it is writing the build
files, but it does not.

This is cmake 2.4.7 on linux.

Any advice?

Juan


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

Re: [CMake] SET_TARGET_PROPERTIES twice

[Juan Sanchez]

Sorry for the trouble.  It turns out my second SET_TARGET_PROPERTIES was
missing the PROPERTIES statement.  The error statement was lost in the
other messages I had in my CMakeLists.txt.

Other issues:

It does appear that a second SET_TARGET_PROPERTIES will replace
properties set in the first statement, without warning.

It also appears that if cmake generated files exist in the source area,
the new cmake files will not be written to the out of source area.

Sorry for the confusion.

Thanks,

Juan


David Cole wrote:
 Does this reproduce in a small case that you could post the source to
 the list? Or, if not, could you post your source as is?
 
 
 On 10/2/07, Juan Sanchez [EMAIL PROTECTED] wrote:
 I just discovered that the moment I add a second SET_TARGET_PROPERTIES
 statement for a specific target, cmake will implicitly fail, and not
 write out a Makefile.  It even states that it is writing the build
 files, but it does not.

 This is cmake 2.4.7 on linux.

 Any advice?

 Juan


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

 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

[CMake] removing invalid output

[Juan Sanchez]

I am using ADD_CUSTOM_COMMAND to produce an output.

Unfortunately, if the commands in it fail, the OUTPUT.  Hence the OUTPUT
is up to date, even though it is invalid.  Is there a way to tell
ADD_CUSTOM_COMMAND to remove its output when it fails?

Thanks,

Juan


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

Re: [CMake] problem creating a library on mac

[Juan Sanchez]

Could this be an issue with linker order?  Most linkers are one pass.
The library containing the undefined references should be on the linker
line before the library containing the symbols, or vice-versa (I keep
forgetting).

Do the libraries contain the symbols that they should?  Use whatever the
nm equivalent on mac os is to check.

Regards,

Juan

Marie-Christine Vallet wrote:
 Mike Jackson wrote:
 What are the errors you are getting on OS X?
 I get an undefined symbol error for several of my variables.
 If I do the linking manually, leaving out the library, and putting the 
 .o of the library and use the same flags, it works.
 Also, at least one comment, I am not sure you want to be setting the 
 PROJECT_BINARY_DIR Variable?

 What are you trying to do with this statement:

 SET(PROJECT_BINARY_DIR
 ${CMAKE_SOURCE_DIR}/bin)

 I just wanted the binary to be in this folder  (and all the files 
 created by cmake to be in this directory so I could clean up my 
 directory more easily )
 ___
 CMake mailing list
 CMake@cmake.org
 http://www.cmake.org/mailman/listinfo/cmake
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] problem creating a library on mac

[Juan Sanchez]

Marie-Christine Vallet wrote:
 Juan Sanchez wrote:
 Could this be an issue with linker order?  Most linkers are one pass.
 The library containing the undefined references should be on the linker
 line before the library containing the symbols, or vice-versa (I keep
 forgetting).

   
 The symbols are part of the newly created library, and they are only 
 reference in the executable
 Do the libraries contain the symbols that they should?  Use whatever the
 nm equivalent on mac os is to check.

nm is a unix tool, which google claims to exist on the mac, which tells
you the name of any symbols that are referenced (but undefined), or are
defined somewhere in the objects of an archive file or binary.

If you have a C++ project, you can do:
nm foo.a | c++ filt

to see the human readable version of the symbols in your archive.

If your linker complains about an undefined symbol, you can go looking
for the symbol in the archive you think it belongs to.

For example:

~ nm ctest/hello | grep main
 U __libc_start_main@@GLIBC_2.0
08048424 T main

Says that main is defined in my binary, but the symbol
__libc_start_main@@GLIBC_2.0 is referenced and undefined.

If it is in the appropriate place, you then need to look at the linker
order on the link line.

Regards,

Juan



   
 what is nm?
 Regards,

 Juan

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


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] Compiling fortran

[Juan Sanchez]

It turns out that any word of the word Use or use as a word anywhere in
a comment causes the dependency scanner to use the next token on the
line as a module dependency.

So I changed all the code to use xUse and xuse.

Thanks,

Juan

Alin M Elena wrote:
 On Wednesday 26 September 2007 04:37:33 [EMAIL PROTECTED] wrote:
 While the cmake man page does not document the proper capitalization of
 Fortran for creating a fortran based project, I am now at the point the
 compilation does not work for another reason.

 Does anyone have an idea what this means?


 Clearing dependencies in CMakeFiles/pisces.dir/depend.make.
 Clearing dependencies in CMakeFiles/pisces.dir/depend.internal.
 /usr/bin/cmake -E cmake_progress_start
 /home/anon/svn/svn_repository/relB.9009/pisces/9009/src/CMakeFiles 50
 make -f CMakeFiles/Makefile2 all
 make[1]: Entering directory
 `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'
 make -f CMakeFiles/pisces.dir/build.make CMakeFiles/pisces.dir/depend
 make[2]: Entering directory
 `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'
 Scanning dependencies of target pisces
 cd /home/anon/svn/svn_repository/relB.9009/pisces/9009/src 
 /usr/bin/cmake -E cmake_depends Unix Makefiles
 /home/anon/svn/svn_repository/relB.9009/pisces/9009/src
 /home/anon/svn/svn_repository/relB.9009/pisces/9009/src
 /home/anon/svn/svn_repository/relB.9009/pisces/9009/src
 /home/anon/svn/svn_repository/relB.9009/pisces/9009/src
 /home/anon/svn/svn_repository/relB.9009/pisces/9009/src/CMakeFiles/pisces.d
 ir/DependInfo.cmake make[2]: Leaving directory
 `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'
 make -f CMakeFiles/pisces.dir/build.make CMakeFiles/pisces.dir/requires
 make[2]: Entering directory
 `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'
 make[2]: *** No rule to make target `new.mod.proxy', needed by
 `CMakeFiles/pisces.dir/filopncls.o.requires'.  Stop.
 make[2]: Leaving directory
 `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'
 make[1]: *** [CMakeFiles/pisces.dir/all] Error 2
 make[1]: Leaving directory
 `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'

 Thanks,

 Juan
 
 Yap It is a feature of cmake (even there are some bug reports about it). 
 You 
 should do (in the root folder of the project, where the CMakeLists.txt 
 resides)
 touch new.mod.proxy
 and the same for any other that complains about.
 
 Alin
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] ctest question

[Juan Sanchez]

Awesome.  I love that guys work on bibtex and bibtools.

Juan

Mathieu MARACHE wrote:
 2007/9/25, Juan Sanchez [EMAIL PROTECTED]:
 Hi Alan,

 I also have floating point results I want to account for.  I'm thinking
 about writing a diff script for numerical results which uses an absolute
 and relative error tolerance.  This would account for the difference in
 transcendentals and other math functions between processors and math
 libraries.  I always disable 80 bit extended precision on linux since
 the results are non-deterministic with respect to compiler settings.
 
 diff with numerical precision concerns is ndiff :
 http://www.math.utah.edu/~beebe/software/ndiff
 
 HTH
 
 Regards,

 Juan


 Alan W. Irwin wrote:
 On 2007-09-24 10:05-0500 Juan Sanchez wrote:

 Hello Alan,

 From your example, what in this statement that causes the test to run
 when I type make test?

 ADD_TEST(my_first_test diff -q goldenfile testfile)

 All it says is to run diff.  How do I tell it to generate the testfile
 from another executable?  How do I tell this executable to run only when
 I type make test and not a moment before?
 Hi Juan:

 In the above simple example diff is run only when you run ctest (or I
 guess make test although I don't use that). So you could do something like

 ADD_TEST(my_first_test ${CMAKE_CURRENT_BINARY_DIR}/create_testfile; diff -q 
 goldenfile testfile)

 subject to escaping of ; which I can never get right until I experiment.
 (This general command-line approach of separating commands with ; only
 works on Unix, I believe.)

 Then the create_testfile executable is run at ctest time to create testfile
 and then diff is run immediately afterwards (which appears to be what you
 want).

 A better approach would be to put everything you want including the diff
 into a configurable script, e.g.,

 ADD_TEST(my_first_test ${CMAKE_CURRENT_BINARY_DIR}/test1.sh)

 Note, in this case, the script is configured using CONFIGURE_FILE at
 cmake time (basically by substituting CMake-defined variables when needed),
 but run only at ctest time.

 Our tests don't use diff (because postscript PLplot results are slightly
 platform/compiler version dependent because of floating-point rounding
 issues), but we do use a configurable scripting approach to generate our
 test plots, see
 http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/test/CMakeLists.txt?view=log

 I don't recommend you wade through _all_ of that CMake logic and bash script
 logic since it is so specific to our PLplot needs (and also its pretty
 voluminous/hierarchical since it deals with hundreds of test plots), but I
 have given you the above starting reference in case you have trouble
 configuring test scripts for yourself using CONFIGURE_FILE.

 Alan
 __
 Alan W. Irwin

 Astronomical research affiliation with Department of Physics and Astronomy,
 University of Victoria (astrowww.phys.uvic.ca).

 Programming affiliations with the FreeEOS equation-of-state implementation
 for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
 package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
 Linux Links project (loll.sf.net); and the Linux Brochure Project
 (lbproject.sf.net).
 __

 Linux-powered Science
 __



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

Re: [CMake] Compiling fortran

[Juan Sanchez]

Hi Bill,

I wouldn't mind taking a stab at it.

It would be easy enough to tell lex to drop any line starting with a
comment character.  Something along the lines of:

^[cC].* {}

There seems to be a line in the lexer that does this, but it doesn't
appear that that the start condition, fixed_fmt, is ever activated.

fixed_fmt^[cC*dD].*\n { return EOSTMT; } /* empty lines */

Do you have any info about how to make submissions and getting the
latest CVS?

Juan



Bill Hoffman wrote:
 Juan Sanchez wrote:
 It turns out that any word of the word Use or use as a word anywhere in
 a comment causes the dependency scanner to use the next token on the
 line as a module dependency.

 So I changed all the code to use xUse and xuse.
   
 The problem is well known, and much talked about.
 The solution is to fix the fortran parser:
 from makefdep90 that is used in CMake.
 
 http://www.cmake.org/pipermail/cmake/2006-September/011072.html
 
 A lex/yacc guru would be best to help out here.   Basically we want
 the fortran parser to ignore all comment lines.  I gave it a try a while
 ago, but did not get it to work.  I suppose a hack solution would be to
 pre-process the files and remove the comments before the parser sees
 it.   If someone does either of those, I would be happy to put it into CVS
 CMake.
 
 -Bill
 


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

Re: [CMake] Compiling fortran

[Juan Sanchez]

Anyone know what are the valid comment lines in all the Fortran variants?

I know of lines beginning with c, C, or * in the first column.

Juan

Bill Hoffman wrote:
 Juan Sanchez wrote:
 Hi Bill,

 I wouldn't mind taking a stab at it.

 It would be easy enough to tell lex to drop any line starting with a
 comment character.  Something along the lines of:

 ^[cC].* {}

 There seems to be a line in the lexer that does this, but it doesn't
 appear that that the start condition, fixed_fmt, is ever activated.

 fixed_fmt^[cC*dD].*\n { return EOSTMT; } /* empty lines */

 Do you have any info about how to make submissions and getting the
 latest CVS?
   
 Instructions for CVS are here:
 
 http://www.cmake.org/HTML/Download.html#cvs
 
 If you get it working, just attach the patch to CVS CMake to the bug in 
 the bug tracker.
 
 -Bill
 
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] CTest and Makefiles

[Juan Sanchez]

Would you happen to have a file named test in your binary area?  Make
will see the file and think that the target test is up to date.

A proper gnu makefile would mark the test target as phony.  Looking at
the gnu makefile generated by one of my projects, test is not marked as
phony.

Let me know if this is the issue.

Thanks,

Juan

KSpam wrote:
 I have a strange problem using CTest with Makefiles.  If I run make test, 
 ctest is never called.  If I change the name of the target in the Makefile 
 from test to test2 and run make test2, then ctest is called properly.
 
 After changing the target name, make test is still recognized as a valid 
 target.  In other words, I do not receive the following error:
 
 make: *** No rule to make target `test'.  Stop.
 
 It seems like make has its own internal test target and it will not use the 
 test target from the Makefile.  Does anyone know what is going on here or how 
 to fix it?
 
 Thanks,
 Justin
 ___
 CMake mailing list
 CMake@cmake.org
 http://www.cmake.org/mailman/listinfo/cmake
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] CTest and Makefiles

[Juan Sanchez]

As a followup.  If I touch test, the test no longer runs.  If I add
the PHONY target to the Makefile.  The tests still run.


 ~/bar make test

Running tests...
Start processing tests
Test project /home/juans/bar
  1/  1 Testing foo  Passed

100% tests passed, 0 tests failed out of 1
 ~/bar make test
Running tests...
Start processing tests
Test project /home/juans/bar
  1/  1 Testing foo  Passed

100% tests passed, 0 tests failed out of 1
 ~/bar touch test
 ~/bar make test
 ~/bar

 ~/bar echo .PHONY: test  Makefile

 ~/bar make test
Running tests...
Start processing tests
Test project /home/juans/bar
  1/  1 Testing foo  Passed



Juan Sanchez wrote:
 Would you happen to have a file named test in your binary area?  Make
 will see the file and think that the target test is up to date.
 
 A proper gnu makefile would mark the test target as phony.  Looking at
 the gnu makefile generated by one of my projects, test is not marked as
 phony.
 
 Let me know if this is the issue.
 
 Thanks,
 
 Juan
 
 KSpam wrote:
 I have a strange problem using CTest with Makefiles.  If I run make test, 
 ctest is never called.  If I change the name of the target in the Makefile 
 from test to test2 and run make test2, then ctest is called properly.

 After changing the target name, make test is still recognized as a valid 
 target.  In other words, I do not receive the following error:

 make: *** No rule to make target `test'.  Stop.

 It seems like make has its own internal test target and it will not use the 
 test target from the Makefile.  Does anyone know what is going on here or 
 how 
 to fix it?

 Thanks,
 Justin
 ___
 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] CTest and Makefiles

[Juan Sanchez]

I preemptively filed bug:

http://www.cmake.org/Bug/view.php?id=5785

I didn't know directories could trigger this as well.

Juan


KSpam wrote:
 Juan,
 
 Thanks for the tip!  Although I did not have a file named test, I did have 
 a 
 directory named test (that contains all of my test projects naturally).  
 Marking the test target as phony in the Makefile resolved the issue.
 
 It sounds like this should be fixed in the Makefile generator.  There are 
 several other targets that should be marked as phony as well.
 
 Thanks,
 Justin
 
 On Wednesday 26 September 2007 09:43:42 Juan Sanchez wrote:
 As a followup.  If I touch test, the test no longer runs.  If I add
 the PHONY target to the Makefile.  The tests still run.


  ~/bar make test

 Running tests...
 Start processing tests
 Test project /home/juans/bar
   1/  1 Testing foo  Passed

 100% tests passed, 0 tests failed out of 1
  ~/bar make test
 Running tests...
 Start processing tests
 Test project /home/juans/bar
   1/  1 Testing foo  Passed

 100% tests passed, 0 tests failed out of 1
  ~/bar touch test
  ~/bar make test
  ~/bar

  ~/bar echo .PHONY: test  Makefile

  ~/bar make test
 Running tests...
 Start processing tests
 Test project /home/juans/bar
   1/  1 Testing foo  Passed

 Juan Sanchez wrote:
 Would you happen to have a file named test in your binary area?  Make
 will see the file and think that the target test is up to date.

 A proper gnu makefile would mark the test target as phony.  Looking at
 the gnu makefile generated by one of my projects, test is not marked as
 phony.

 Let me know if this is the issue.

 Thanks,

 Juan

 KSpam wrote:
 I have a strange problem using CTest with Makefiles.  If I run make
 test, ctest is never called.  If I change the name of the target in the
 Makefile from test to test2 and run make test2, then ctest is
 called properly.

 After changing the target name, make test is still recognized as a
 valid target.  In other words, I do not receive the following error:

 make: *** No rule to make target `test'.  Stop.

 It seems like make has its own internal test target and it will not use
 the test target from the Makefile.  Does anyone know what is going on
 here or how to fix it?

 Thanks,
 Justin


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

[CMake] include directories variable?

[Juan Sanchez]

How do I get the INCLUDE_DIRECTORIES path?  I need to feed into into the
search path for the swig command line.

Thanks,

Juan


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

Re: [CMake] ctest question

[Juan Sanchez]

Hi Alan,

I also have floating point results I want to account for.  I'm thinking
about writing a diff script for numerical results which uses an absolute
and relative error tolerance.  This would account for the difference in
transcendentals and other math functions between processors and math
libraries.  I always disable 80 bit extended precision on linux since
the results are non-deterministic with respect to compiler settings.

Regards,

Juan


Alan W. Irwin wrote:
 On 2007-09-24 10:05-0500 Juan Sanchez wrote:
 
 Hello Alan,

 From your example, what in this statement that causes the test to run
 when I type make test?

 ADD_TEST(my_first_test diff -q goldenfile testfile)

 All it says is to run diff.  How do I tell it to generate the testfile
 from another executable?  How do I tell this executable to run only when
 I type make test and not a moment before?
 
 Hi Juan:
 
 In the above simple example diff is run only when you run ctest (or I
 guess make test although I don't use that). So you could do something like
 
 ADD_TEST(my_first_test ${CMAKE_CURRENT_BINARY_DIR}/create_testfile; diff -q 
 goldenfile testfile)
 
 subject to escaping of ; which I can never get right until I experiment.
 (This general command-line approach of separating commands with ; only
 works on Unix, I believe.)
 
 Then the create_testfile executable is run at ctest time to create testfile
 and then diff is run immediately afterwards (which appears to be what you
 want).
 
 A better approach would be to put everything you want including the diff
 into a configurable script, e.g.,
 
 ADD_TEST(my_first_test ${CMAKE_CURRENT_BINARY_DIR}/test1.sh)
 
 Note, in this case, the script is configured using CONFIGURE_FILE at
 cmake time (basically by substituting CMake-defined variables when needed),
 but run only at ctest time.
 
 Our tests don't use diff (because postscript PLplot results are slightly
 platform/compiler version dependent because of floating-point rounding
 issues), but we do use a configurable scripting approach to generate our
 test plots, see
 http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/test/CMakeLists.txt?view=log
 
 I don't recommend you wade through _all_ of that CMake logic and bash script
 logic since it is so specific to our PLplot needs (and also its pretty
 voluminous/hierarchical since it deals with hundreds of test plots), but I
 have given you the above starting reference in case you have trouble
 configuring test scripts for yourself using CONFIGURE_FILE.
 
 Alan
 __
 Alan W. Irwin
 
 Astronomical research affiliation with Department of Physics and Astronomy,
 University of Victoria (astrowww.phys.uvic.ca).
 
 Programming affiliations with the FreeEOS equation-of-state implementation
 for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
 package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
 Linux Links project (loll.sf.net); and the Linux Brochure Project
 (lbproject.sf.net).
 __
 
 Linux-powered Science
 __
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

[CMake] ctest question

[Juan Sanchez]

I want run a test program and pipe its results to a file.  I then want
to compare this file to the golden results using diff.

Does anyone have a macro or cookbook example for doing this?

Thank you,

Juan


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

Re: [CMake] override variable in macro

[Juan Sanchez]

I would argue that the following snippet of code should either print
CAT twice or die.  Unfortunately it first prints DOG and then CAT.

Thanks,

Juan

MACRO(FOO BAR)
  SET (BAR CAT)
  MESSAGE(${BAR})
ENDMACRO(FOO)

FOO(DOG)
MESSAGE(${BAR})



Bill Hoffman wrote:
 Juan Sanchez wrote:
 What I was trying to do was to avoid having to create a local variable.
  The macro parameter is the default, which can be overridden if necessary.

 Now I immediately have to set a new variable with the value of the
 parameter.  So I now have to account for another variable being created
 which may then escape the macro's namespace.

 Can we have the SET command fail on trying to set a macro parameter?
   
 You are thinking about macros in the wrong way.   Think of them as c or 
 c++ #define macro's.
 Basically, they do nothing more than string replacement. 
 
 -Bill
 
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] override variable in macro

[Juan Sanchez]

Ok,

But cpp doesn't discriminate between ${BAR} and BAR.
#include iostream
using namespace std;
#define foo(x) x = 3; cout  x  \n;

int main()
{
  int y = 1;
  foo(y);
  cout  y  endl;
}

Juan





Bill Hoffman wrote:
 Juan Sanchez wrote:
 I would argue that the following snippet of code should either print
 CAT twice or die.  Unfortunately it first prints DOG and then CAT.

 Thanks,

 Juan

 MACRO(FOO BAR)
   SET (BAR CAT)
   MESSAGE(${BAR})
 ENDMACRO(FOO)

 FOO(DOG)
 MESSAGE(${BAR})

   
 So, expand the macro and you get:
 
 SET(BAR CAT)   # text in a macro is just text, BAR is just more text
 MESSAGE(DOG)  # ${BAR} is replaced by DOG sort of like a cpp macro
 MESSAGE(${BAR})  # now we print BAR which was set to CAT in the macro
 
 -Bill
 
 
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

[CMake] target_link_libraries external library

[Juan Sanchez]

Hello,

How do you add an externally library for linking into a target?  I am
getting something like this from TARGET_LINK_LIBRARIES?

CMake Error: Attempt to add link library /bar/linux-x86/opt/foo.a to
target waterlooApps which is not built by this project.

Thanks,

Juan



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

[CMake] override variable in macro

[Juan Sanchez]

It appears that the set command cannot override a variable specified as
a MACRO argument.

For example:
 MACRO (ADD_GADB RCMD)

does not accept changes to RCMD within the macro using the set command.
 Is there a way to override this?

Thanks,

Juan


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

Re: [CMake] Creating a static lib from other static libs, HOW?

[Juan Sanchez]

I guess you'd have to come up with a way of renaming each object file
with a prefix special to each original archive.  The v option (GNU ar)
will tell you the name object being extracted.  Maybe you can use an
external script to automate the process of renaming the files as they
are being extracted.

Even with Brandon's solution, I don't think ar let you add multiple .o
files of the same name in the archive.  The symbols of the first .o file
will get replaced by the symbols of the second .o file to be added.

Juan

Goswin von Brederlow wrote:
 Juan Sanchez [EMAIL PROTECTED] writes:
 
 Hello,

 The ar command can be used to extract the .o files from a .a file.
 Extracting them all into the same directory, perhaps you can use some
 file globbing to find all the objects and add them to another archive.

 Juan
 
 I tried that. It fails if two *.o files have the same name as I noticed.
 
 MfG
 Goswin
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] Creating a static lib from other static libs, HOW?

[Juan Sanchez]

Hello Brandon,

How do you create the final archive without the ar command?

Juan

Brandon Van Every wrote:
 On 9/18/07, Juan Sanchez [EMAIL PROTECTED] wrote:
 Even with Brandon's solution, I don't think ar let you add multiple .o
 files of the same name in the archive.
 
 I'm going to guess you meant, Even with Brandon's solution that
 doesn't use AR, you can't add multiple .o files of the same name to a
 library.  I'm not sure about that.  When I pass CMake objects to a
 library, I provide qualified pathnames, so I don't know if the name of
 the object file matters.  You can't have multiple function
 definitions, but that's about the code, not the object files.  I've
 not had to deal with this issue myself.  You'd need to try my way and
 see what happens.
 
 
 Cheers,
 Brandon Van Every
 ___
 CMake mailing list
 CMake@cmake.org
 http://www.cmake.org/mailman/listinfo/cmake
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] Creating a static lib from other static libs, HOW?

[Juan Sanchez]

To be posix compliant, the path name is not to be encoded into the
archive.  While I was able to create an archive

ar crv foo.a A/a.o B/a.o

and the symbols from both object appeared, this doesn't seem to be very
safe.  Especially since doing this:

ar crv foo.a A/a.o
ar crv foo.a B/a.o

will result in an archive with only the symbols from B/a.o.

There is a non-posix compliant extension to gnu ar, but it seems to be
fraught with peril.

From the ar manpage:
   P   Use the full path name when matching names in the archive.
GNU  ar
   can  not create an archive with a full path name (such
archives are
   not POSIX complaint), but other archive creators can.  This
option
   will  cause  GNU ar to match file names using a complete path
name,
   which can be convenient when  extracting  a  single  file
from  an
   archive created by another tool.


Juan Sanchez wrote:
 Hello Brandon,
 
 How do you create the final archive without the ar command?
 
 Juan
 
 Brandon Van Every wrote:
 On 9/18/07, Juan Sanchez [EMAIL PROTECTED] wrote:
 Even with Brandon's solution, I don't think ar let you add multiple .o
 files of the same name in the archive.
 I'm going to guess you meant, Even with Brandon's solution that
 doesn't use AR, you can't add multiple .o files of the same name to a
 library.  I'm not sure about that.  When I pass CMake objects to a
 library, I provide qualified pathnames, so I don't know if the name of
 the object file matters.  You can't have multiple function
 definitions, but that's about the code, not the object files.  I've
 not had to deal with this issue myself.  You'd need to try my way and
 see what happens.


 Cheers,
 Brandon Van Every
 ___
 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

[CMake] --whole-archive

[Juan Sanchez]

Hi,

On linux, I need to generate an shared library from an archive.  I need
to have:

-Wl,-whole-archive

before and

-Wl,-no-whole-archive

after the archive on the shared library link line.  Is there a way to do
this.  The static archive is compiled fPIC so symbol relocation is not
an issue.

Thanks,

Juan
-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] --whole-archive

[Juan Sanchez]

After some extensive googling, I found the solution here.

http://www.mail-archive.com/cmake@cmake.org/msg01890.html



Juan Sanchez wrote:
 Hi,
 
 On linux, I need to generate an shared library from an archive.  I need
 to have:
 
 -Wl,-whole-archive
 
 before and
 
 -Wl,-no-whole-archive
 
 after the archive on the shared library link line.  Is there a way to do
 this.  The static archive is compiled fPIC so symbol relocation is not
 an issue.
 
 Thanks,
 
 Juan


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

[CMake] faq update?

[Juan Sanchez]

The FAQ doesn't mention the trick for loading a shared library from a
static one.  They therefore think their objects have to be compiled
twice, even when they are using -fPIC on gcc and want the same compiler
flags.

http://www.mail-archive.com/cmake@cmake.org/msg01890.html

Could this be updated?  This FAQ entry is scaring some of my colleagues:

That means I have to build all my library objects twice, once for shared
and once for static. I don't like that!

and they are on the prowl for cmake dealbreakers.

Thanks,

Juan

-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

[CMake] how to track package dependencies

[Juan Sanchez]

What would be the best way to tackle having dependencies with multiple
packages?  For example, if package A depends on both packages B and C:

1. To make sure the compiler is the same
2. Know what flags where used for the sources in the dependency
3. Know whether or not the static archive is position independent
4. If package B and C are both dependent on D, that both are using the
same version when creating package A.

Thanks,

Juan


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

Re: [CMake] faq update?

[Juan Sanchez]

Hello Brandon,

This is the way they are choosing to do this in our organization.  We
only build for gcc on Linux.  If we built for multiple platforms, we
could have platform specific conditional statements, as in the
hyperlinked example I have provided.

In deference to elegance, the project will now compile in half the time.

The statement in the FAQ is untrue:

 That means I have to build all my library objects twice, once for shared
 and once for static. I don't like that!

This statement may also be a dealbreaker for those maintaining huge
projects.

If we choose to use the exact same flags, why shouldn't we be able to
choose to create the shared library from the archive?

If you have something in the FAQ, shouldn't it provide the option for
people who are concerned with the inefficiency of compiling object files
twice?

It is not a hack.  It is the way ld works on linux, and I think that it
is a valid approach.  I'd prefer not to engage in wiki wars where I
replace the untrue statement, with a technically correct hack.  Then
someone goes and changes it back.

Juan

Brandon Van Every wrote:
 On 9/13/07, Juan Sanchez [EMAIL PROTECTED] wrote:
 The FAQ doesn't mention the trick for loading a shared library from a
 static one.  They therefore think their objects have to be compiled
 twice, even when they are using -fPIC on gcc and want the same compiler
 flags.

 http://www.mail-archive.com/cmake@cmake.org/msg01890.html
 
 This looks like a horrible GCC specific hack.  Why should such a thing
 be in the FAQ?  I would think the FAQ should contain advice that's
 good CMake practice and works cross-platform with all the compilers.
 Let's distinguish between Frequently Asked Questions and general
 repositories of tips and tricks tricks.  There are other sections of
 the wiki where you could put a GCC-specific trick.
 
 Could this be updated?
 
 http://www.cmake.org/Wiki/CMake_FAQ is a wiki so yes you could
 personally update it.  But I think others should weigh in about
 whether or not you should.
 
 This FAQ entry is scaring some of my colleagues:

 That means I have to build all my library objects twice, once for shared
 and once for static. I don't like that!

 and they are on the prowl for cmake dealbreakers.
 
 Well they're actually going to do cross-platform work with compilers
 other than GCC, they can't rely on GCC behavior to solve all their
 problems.  So dealbreak away.  Politically, do they know they actually
 need MSVC support?  Or are they in the gee we're Unix, why CMake?
 stage.  There's nothing you can do about the latter unless you have a
 pressing need or desire for cross-platform support.
 
 
 Cheers,
 Brandon Van Every


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

Re: [CMake] faq update?

[Juan Sanchez]

Hello Brandon,

At the end of the day.  The question I answered was frequently asked on
the mailing list (according to google), and inaccurately answered in the
FAQ.

This issue is a concern for many people, and at least one other person
found it helpful.

While beyond my capabilities, I think a cmake macro which does the right
thing for all working platforms would be helpful.  Barring, that, I
think I have presented a practical solution.

Regards,

Juan

Brandon Van Every wrote:
 On 9/13/07, KSpam [EMAIL PROTECTED] wrote:
 What is the point of having a Wiki if not to document such things?  Anyone 
 can
 figure out basic CMake usage from CMake docs.  This is beyond the scope of
 CMake docs; therefore, it belongs on the Wiki.
 
 It's not about what belongs in the wiki.  It's about what belongs in
 the *FAQ*.  The FAQ is an ambassador for CMake best practices.  FAQs
 that sprawl are not very useful.  We've got the entire wiki to put
 stuff on, it doesn't have to all go in the FAQ.
 
 It might be a dealbreaker if we don't have this stuff in the FAQ is
 also the wrong argument.  CMake FAQs cannot solve fundamental problems
 of political will.  If a committee is harping on this or that detail
 of a build system, without assigning responsibility for a pilot
 project, then they aren't serious.  They are looking for reasons to
 avoid a decision, rather than getting on with producing results.
 
 I don't have a problem with these hacks / workarounds being in the FAQ
 if the limitations upon their use are well explained.  Emphasis on
 *well* explained.  New information for a specific corner case should
 not muddy the waters for the vast majority of CMake users out there.
 What most CMake users need to know is, they were wrong that they
 thought they could re-use their differently compiled SHARED and STATIC
 objects.  The number of users who have shown up on this list, who
 really really did have identical flags and really really can reuse
 them, is pretty low.  I'm one of 'em and my solution is better than
 most other people's, in that it's not compiler or platform specific.
 Unfortunately it does rely on CMake internals to get the job done.
 
 For the record, my projects build on many different platforms.  This is not a
 gcc-only hack, as several other compilers provide similar functionality.
 
 But you will still have to spend time maintaining cases for different 
 compilers.
 
 The
 bottom line now is that I can compile my *nix builds twice as fast as my VS8
 Windows builds.  This is quite helpful for *nix users,
 
 Whereas in my case I don't have to do anything special at all on any
 platform.  No compiler case magic, nuthin'.  I can reuse what is
 reusable on any platform.  The drawback is the method for extracting
 object locations can break if Kitware decides to change it.
 
 and it doesn't cost Windows users anything.
 
 Yes it does.  The development time to do things 2 different ways for
 Windows vs. Unix.  A build system like CMake is supposed to
 *alleviate* that, not spawn corner cases where you routinely do that.
 
 I am thoroughly amazed at the combative nature I have witnessed on this
 mailing list.  Quite unprofessional IMHO.
 
 I'm of the mindset that if you're prefacing your solutions with well
 this only works for Unix then you don't really get what
 cross-platform build solutions are about.  We don't care, we know
 we're only going to be messing with Unix is a valid answer for your
 personal needs, I'll admit.  But it's not valid as a best practice to
 promote to CMake initiates.  If a FAQ is going to contain that info,
 then it should make it clear how you're defeating the cross-platform
 capabilities of the build tool.
 
 YES I would like to see CMake handle this automagically.  Then the
 angst and gnashing of teeth goes away.  My solution is very easy to
 implement, and it's easy for the user to employ, but requires that
 Kitware freeze a public interface to the object file locations.  I
 don't know if they're willing to do that.
 
 
 Cheers,
 Brandon Van Every
 ___
 CMake mailing list
 CMake@cmake.org
 http://www.cmake.org/mailman/listinfo/cmake
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

[CMake] making two targets with similar names

[Juan Sanchez]

I am having the following issue.  I want to create both a libFOO.a and a
libFOO.so.  Note that the libFOO.so is composed of more sources than the
libFOO.a.

I use OUTPUT_NAME in order so they have the same name.  I can make the
FOOSTATIC, libFOO.a, target, just fine.  However, making the FOODYNAMIC,
libFOO.so, target deletes libFOO.a, just before linking against it.
This causes a build error.

Is there anyway to prevent this from happening?


ADD_LIBRARY (FOOSTATIC  STATIC ${UDB_SRCS})
ADD_LIBRARY (FOODYNAMIC SHARED ${PERL_SRCS})

target_link_libraries(FOODYNAMIC  FOOSTATIC)

SET_TARGET_PROPERTIES(FOODYNAMIC PROPERTIES
LINK_FLAGS --whole-archive
OUTPUT_NAME   FOO
)

SET_TARGET_PROPERTIES(FOOSTATIC PROPERTIES
OUTPUT_NAME   FOO
)


Thanks,

Juan


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

Re: [CMake] making two targets with similar names

[Juan Sanchez]

Hi Bill,

Thanks, it works when I do this in SET_TARGET_PROPERTIES.

Juan

Juan Sanchez wrote:
 Hi Bill,
 
 What's the proper syntax? Setting the variable in CMakeLists.txt doesn't
 work.  Neither does setting it in my initial Cache file (loaded with
 cmake -C).
 
 SET (CLEAN_DIRECT_OUTPUT 1 CACHE STRING 1)
 
 Thanks,
 
 Juan
 
 Bill Hoffman wrote:
 Juan Sanchez wrote:
 I am having the following issue.  I want to create both a libFOO.a and a
 libFOO.so.  Note that the libFOO.so is composed of more sources than the
 libFOO.a.

 I use OUTPUT_NAME in order so they have the same name.  I can make the
 FOOSTATIC, libFOO.a, target, just fine.  However, making the FOODYNAMIC,
 libFOO.so, target deletes libFOO.a, just before linking against it.
 This causes a build error.

 Is there anyway to prevent this from happening?


 ADD_LIBRARY (FOOSTATIC  STATIC ${UDB_SRCS})
 ADD_LIBRARY (FOODYNAMIC SHARED ${PERL_SRCS})

 target_link_libraries(FOODYNAMIC  FOOSTATIC)

 SET_TARGET_PROPERTIES(FOODYNAMIC PROPERTIES
 LINK_FLAGS --whole-archive
 OUTPUT_NAME   FOO
 )

 SET_TARGET_PROPERTIES(FOOSTATIC PROPERTIES
 OUTPUT_NAME   FOO
 )
   
 See the documentation for OUTPUT_NAME:

 When a library is built CMake by default generates code to remove any 
 existing library using all possible names. This is needed to support 
 libraries that switch between STATIC and SHARED by a user option. 
 However when using OUTPUT_NAME to build a static and shared library of 
 the same name using different logical target names the two targets will 
 remove each other's files. This can be prevented by setting the 
 CLEAN_DIRECT_OUTPUT property to 1.


 -Bill



 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] making two targets with similar names

[Juan Sanchez]

Hi Bill,

What's the proper syntax? Setting the variable in CMakeLists.txt doesn't
work.  Neither does setting it in my initial Cache file (loaded with
cmake -C).

SET (CLEAN_DIRECT_OUTPUT 1 CACHE STRING 1)

Thanks,

Juan

Bill Hoffman wrote:
 Juan Sanchez wrote:
 I am having the following issue.  I want to create both a libFOO.a and a
 libFOO.so.  Note that the libFOO.so is composed of more sources than the
 libFOO.a.

 I use OUTPUT_NAME in order so they have the same name.  I can make the
 FOOSTATIC, libFOO.a, target, just fine.  However, making the FOODYNAMIC,
 libFOO.so, target deletes libFOO.a, just before linking against it.
 This causes a build error.

 Is there anyway to prevent this from happening?


 ADD_LIBRARY (FOOSTATIC  STATIC ${UDB_SRCS})
 ADD_LIBRARY (FOODYNAMIC SHARED ${PERL_SRCS})

 target_link_libraries(FOODYNAMIC  FOOSTATIC)

 SET_TARGET_PROPERTIES(FOODYNAMIC PROPERTIES
 LINK_FLAGS --whole-archive
 OUTPUT_NAME   FOO
 )

 SET_TARGET_PROPERTIES(FOOSTATIC PROPERTIES
 OUTPUT_NAME   FOO
 )
   
 See the documentation for OUTPUT_NAME:
 
 When a library is built CMake by default generates code to remove any 
 existing library using all possible names. This is needed to support 
 libraries that switch between STATIC and SHARED by a user option. 
 However when using OUTPUT_NAME to build a static and shared library of 
 the same name using different logical target names the two targets will 
 remove each other's files. This can be prevented by setting the 
 CLEAN_DIRECT_OUTPUT property to 1.
 
 
 -Bill
 
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

[CMake] dependency checking

[Juan Sanchez]

I've been trying to find a good explanation of how the /fast target
works online?  Is there a place where the exact behavior documented?

Also my concern is that adding a source file to CMakeLists.txt file
triggers a rebuild of all source files?  Can this be averted by having
cmake discover the source files instead of me specifying them?

Is there a better way of preventing rebuilds when I know that my changes
don't invalidate the object files I already have compiled?

Regards,

Juan

-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] dependency checking

[Juan Sanchez]

I just added a source file to the list of sources in my library and now
it is recompiling every source file in that library.  I don't feel
rebuilding the other source files is necessary and I'd like a way to
tell cmake to trust me and that any object files I have are still good.


Regards,

Juan


Alexander Neundorf wrote:
 On Thursday 09 August 2007 12:57, Juan Sanchez wrote:
 I've been trying to find a good explanation of how the /fast target
 works online?  Is there a place where the exact behavior documented?

 Also my concern is that adding a source file to CMakeLists.txt file
 triggers a rebuild of all source files?  Can this be averted by having
 
 No, it doesn't.
 You really only get rebuilds if they are required (e.g. if a header changes 
 or 
 if some compile flag is changed).
 
 Bye
 Alex
 ___
 CMake mailing list
 CMake@cmake.org
 http://www.cmake.org/mailman/listinfo/cmake
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] dependency checking

[Juan Sanchez]

Hi Bill,

I ran a test and figured out what is triggering the problem.  The
problem is that I have SET_SOURCE_FILES_PROPERTIES which operates on
${SRCS}.  By adding to ${SRCS} it triggers the rebuild of all of the
files listed, and not just of the one I added.

If I comment out SET_SOURCE_FILES_PROPERTIES, I can add or remove files
from ${SRCS} without retriggering costly rebuilds.

Is there any way to change this behavior?  Unfortunately the project I
am porting has source files for multiple libraries in the same
directory.  I'd hate to have to list each file individually.

Regards,

Juan

PROJECT(main)
SET (SRCS  a.cc b.cc c.cc d.cc e.cc f.cc g.cc)
ADD_EXECUTABLE(a ${SRCS})
ADD_LIBRARY(b ${SRCS})
SET_SOURCE_FILES_PROPERTIES (
  ${SRCS}
  COMPILE_FLAGS -Wall
)


Bill Hoffman wrote:
 Juan Sanchez wrote:
 I just added a source file to the list of sources in my library and now
 it is recompiling every source file in that library.  I don't feel
 rebuilding the other source files is necessary and I'd like a way to
 tell cmake to trust me and that any object files I have are still good.
   
 Either that is a bug, or a compiler flag has changed.   CMake should 
 only rebuild object files if
 the source (including headers) for that file changes, or if the flags 
 used to compile that object
 file changes.
 
 make -d can be used to figure out why make is rebuilding the object files.
 
 
 -Bill
 
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] dependency checking

[Juan Sanchez]

The problem still exists after adding the PROPERTIES keyword.

Thanks,

Juan

Alexander Neundorf wrote:
 On Thursday 09 August 2007 13:32, you wrote:
 Hi Bill,

 I ran a test and figured out what is triggering the problem.  The
 problem is that I have SET_SOURCE_FILES_PROPERTIES which operates on
 ${SRCS}.  By adding to ${SRCS} it triggers the rebuild of all of the
 files listed, and not just of the one I added.

 If I comment out SET_SOURCE_FILES_PROPERTIES, I can add or remove files
 from ${SRCS} without retriggering costly rebuilds.
 ...
 SET_SOURCE_FILES_PROPERTIES (
   ${SRCS}
   COMPILE_FLAGS -Wall
 )
 
 I didn't test, but here the PROPERTIES keyword is missing. Is it just a 
 copy'n 
 paste error or does it still happen if you insert it ?
 
 Alex
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] Re: problems compilating 2.4.7 under 2.2

[Juan Sanchez]

Matthew Woehlke wrote:
 Alex Dantart wrote:
 Matthew Woehlke wrote:
 Alex Dantart wrote:
.
.
.
 Anyway, this line seems to be the important clue:
 /usr/bin/ld: crt1.o No hay tal fichero: No existe el fichero ó directorio
 
 It looks almost like your compiler is not installed properly? Are you 
 able to compile and link a simple 'hello world!' program?

ld is the linker.  On a redhat system it's in the binutils package.  I
have no idea where it would be on ubuntu.  It is independent of the
compiler.

Regards,

Juan



-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] Re: problems compilating 2.4.7 under 2.2

[Juan Sanchez]

In addition, if it is crt1.o which is missing, it is in glibc-devel on a
redhat 7.3 system.

Regards,

Juan

Juan Sanchez wrote:
 Matthew Woehlke wrote:
 Alex Dantart wrote:
 Matthew Woehlke wrote:
 Alex Dantart wrote:
 .
 .
 .
 Anyway, this line seems to be the important clue:
 /usr/bin/ld: crt1.o No hay tal fichero: No existe el fichero ó directorio
 It looks almost like your compiler is not installed properly? Are you 
 able to compile and link a simple 'hello world!' program?

 ld is the linker.  On a redhat system it's in the binutils package.  I
 have no idea where it would be on ubuntu.  It is independent of the
 compiler.
 
 Regards,
 
 Juan
 
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] Re: problems compilating 2.4.7 under 2.2

[Juan Sanchez]

Please see:
http://felixker.com/tips-and-tricks/crt1o-no-such-file-no-such-file-or-directory/

From the article (the Fedora instructions make no sense at all):

 While using gcc on a newly installed system you may get:
/usr/bin/ld: crt1.o: No such file: No such file or directory

This is a common problem, but with a simple solution.

On debian:
apt-get install libc6-dev

On Fedora:

$ locate crt1.o
/usr/lib/crt1.o

On Ubuntu:
apt-get install libc6-dev

{ If not root, sudo apt-get install libc6-dev }

Juan Sanchez wrote:
 In addition, if it is crt1.o which is missing, it is in glibc-devel on a
 redhat 7.3 system.
 
 Regards,
 
 Juan
 
 Juan Sanchez wrote:
 Matthew Woehlke wrote:
 Alex Dantart wrote:
 Matthew Woehlke wrote:
 Alex Dantart wrote:
 .
 .
 .
 Anyway, this line seems to be the important clue:
 /usr/bin/ld: crt1.o No hay tal fichero: No existe el fichero ó directorio
 It looks almost like your compiler is not installed properly? Are you 
 able to compile and link a simple 'hello world!' program?

 ld is the linker.  On a redhat system it's in the binutils package.  I
 have no idea where it would be on ubuntu.  It is independent of the
 compiler.

 Regards,

 Juan



 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

[CMake] big custom command dependency problem

[Juan Sanchez]

I created a custom command to generate a cpp file.

I then use this cpp file to create a library as a separate add_library
command.

Whenever I type make, this cpp file is regenerated, and the library is
recreated.  Compiling this file is super expensive.  Nothing has changed
between invocations of make.

I stated the dependencies in the custom command.  Why is it always
recreating the cpp file?

Is there anyway to stop this behavior?

Turning off dependency checking is not an option since it is needed for
everything else.  This is gmake on a linux box.

Thanks,

Juan


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

Re: [CMake] big custom command dependency problem

[Juan Sanchez]

I found the problem.  The output from the custom command has to
explicitly specify the destination path of the output file.

OUTPUT ${PROJECT_BINARY_DIR}/output.cc

I was already specifying the full path for the input to the library.

Regards,

Juan


Juan Sanchez wrote:
 I created a custom command to generate a cpp file.
 
 I then use this cpp file to create a library as a separate add_library
 command.
 
 Whenever I type make, this cpp file is regenerated, and the library is
 recreated.  Compiling this file is super expensive.  Nothing has changed
 between invocations of make.
 
 I stated the dependencies in the custom command.  Why is it always
 recreating the cpp file?
 
 Is there anyway to stop this behavior?
 
 Turning off dependency checking is not an option since it is needed for
 everything else.  This is gmake on a linux box.
 
 Thanks,
 
 Juan
 
 
 ___
 CMake mailing list
 CMake@cmake.org
 http://www.cmake.org/mailman/listinfo/cmake
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

[CMake] Passing -B on linux

[Juan Sanchez]

When I create a new cmake area, the tests are failing since it cannot
find the 64bit version of our tools on linux.

Is there anyway to pass the -B option to C and C++ compiler during the
compiler testing phase?

Thanks,

Juan
-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] Passing -B on linux

[Juan Sanchez]

Hello gga,

Unfortunately, the ADD_DEFINITIONS aren't being used in the initial
tests being done by cmake.  What I've found is that I need to put the
location of the 64bit linker utils needed by g++ in my PATH.  In this
instance, its calling the wrong assembler.  The assembler is implicitly
called by g++ and -B would allow me to set the path.


Building CXX object CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.o
/.package/gcc-3.4.0/bin/g++-o
CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.o -c
/test/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
/tmp/ccRjnwzu.s: Assembler messages:
/tmp/ccRjnwzu.s:8: Error: suffix or operands invalid for `push'
/tmp/ccRjnwzu.s:10: Error: suffix or operands invalid for `movq'
gmake[1]: *** [CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.o] Error 1
gmake[1]: Leaving directory `/test/CMakeFiles/CMakeTmp'
gmake: *** [cmTryCompileExec/fast] Error 2


Is there any way to pass a flag to g++ being invoked by the testing
utils?  I'm at least able to put the c++ compiler specification in a
cache file, but I need to know how to prevent the path to the linker
utils to be at the whim of the developer's environment.

Regards,

Juan

gga wrote:
 Juan Sanchez wrote:
 When I create a new cmake area, the tests are failing since it cannot
 find the 64bit version of our tools on linux.

 
 Assuming they are installed in /usr/local or /usr, one should expect
 that to be automatic. That being said...
 
 Is there anyway to pass the -B option to C and C++ compiler during the
 compiler testing phase?

 
 Yes.  ADD_DEFINITIONS() can be used to pass any flag to both compiler
 and linker.
 
 For more granularity, you can use:
 SET_SOURCE_FILES_PROPERTIES with the COMPILE_FLAGS property.
 SET_TARGET_PROPERTIES with the LINK_FLAGS property.
 
 Needless to say, a flag like -B will not be portable across compilers,
 so you'll need to check for the compiler you are using.
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] get includes

[Juan Sanchez]

It looks like it should work.

Thanks,

Juan

Alexander Neundorf wrote:
 On Wednesday 01 August 2007 18:53, Juan Sanchez wrote:
 Is it possible to get the include paths from ADD_DIRECTORIES into a
 custom command?  I need to pass along the include path for a special
 swig invocation.
 
 Does get_directory_property( incDirs INCLUDE_DIRECTORIES) what you want ?
 
 Alex
 ___
 CMake mailing list
 CMake@cmake.org
 http://www.cmake.org/mailman/listinfo/cmake
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] Passing -B on linux

[Juan Sanchez]

Hi Bill,

I was able to add CMAKE_CXX_FLAGS to my initial cache file and it
worked.  Thanks for the clarification.

Thanks,

Juan

Bill Hoffman wrote:
 Juan Sanchez wrote:
 Hello gga,

 Unfortunately, the ADD_DEFINITIONS aren't being used in the initial
 tests being done by cmake.  What I've found is that I need to put the
 location of the 64bit linker utils needed by g++ in my PATH.  In this
 instance, its calling the wrong assembler.  The assembler is implicitly
 called by g++ and -B would allow me to set the path.
   
 If you set environment variables BEFORE running cmake, it should use 
 them in the try compile
 stuff:
 
 Something like this:
 
 export CXX=g++
 export CXXFLAGS=-64
 export LDFLAGS=-64
 export CFLAGS=-64
 
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

[CMake] get includes

[Juan Sanchez]

Is it possible to get the include paths from ADD_DIRECTORIES into a
custom command?  I need to pass along the include path for a special
swig invocation.

Regards,

Juan

-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

Re: [CMake] Eclipse CDT4 CMake Generator - Pre-Alpha version

[Juan Sanchez]

Alexander Neundorf wrote:
 Hi Miguel,
.
.
.

 The indentation is not completely correct:

   if (!fout) { return; }

Hello,

Are there any cindent settings to do auto-indenting for the coding
standards?

Regards,

Juan

Alexander Neundorf wrote:
 Hi Miguel,
 
 On Tuesday 31 July 2007 13:42, Miguel A. Figueroa-Villanueva wrote:
 On 7/31/07, Alexander Neundorf wrote:
 On Tuesday 31 July 2007 09:51, you wrote:
 ...

 Great! If you personally think this is good and can review/apply the
 patches relatively quickly then that will work well for me. What I was
 worried about was that I open a feature request and, understandably
 so, it sits there to be taken care according to everyone's busy
 schedule...

 I sent the patch to the list last night, but it rejected the e-mail
 because it was too big... I'll now clean up the code according to the
 coding style and resend with cc to you. This time tared and zipped, so
 it shouldn't have a problem.
 Thanks :-)
 Attached is the file. I changed some variable names and other minor
 things, but I'm not certain it follows all the coding standards. I
 leave that to your inspection, although please point out whatever you
 find that you needed to fix for my future reference.
 
 It looks quite good :-)
 
 The indentation is not completely correct:
 
   if (!fout) { return; }
 
   if(emmited.find(t-first) == emmited.end())
   {
 emmited.insert(t-first);
 this-AppendTarget(fout, t-first);
   }
 
 should be (indented braces)
 
   if (!fout) 
 { 
 return; 
 }
 
   if(emmited.find(t-first) == emmited.end())
 {
 emmited.insert(t-first);
 this-AppendTarget(fout, t-first);
 }
 
 
 How do you handle the cmake projects ? You iterate over the map, which effect 
 does this have ?
 
 From the header:
 enum ToolChainType { OTHER, LINUX, CYGWIN, MINGW, SOLARIS, MACOSX };
 I would prefer more specific names, e.g. prefixing them 
 with EclipseToolchain, so that you have EclipseToolchainCygwin etc.
 
 One thing which would be nice is if you would also put the include 
 directories 
 in the project files, I think this is required for autocompletion. You can 
 get them via cmMakefile::GetIncludeDirectories().
 
 Do you already setup up running and debugging ?
 I don't know how this works with Eclipse, for KDevelop I put the first 
 executable target I found in the entry where it expects the executable to be 
 debugged.
 
 Can you tell Eclipse to open a file when the project is loaded the first 
 time ? Looks much friendlier then. If this is possible, just use the first 
 source file or the first main.* file you find.
 
 For the KDevelop generator I implemented a simple logic which reads the 
 project files it created on a previous cmake run (and which may have been 
 modified in the meantime by kdevelop) and just modifies what it needs to 
 change, so user changes (like which plugins to load, source control config 
 etc.) stay unchanged.
 
 Bye
 Alex
 ___
 CMake mailing list
 CMake@cmake.org
 http://www.cmake.org/mailman/listinfo/cmake
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

[CMake] set variable in if block

[Juan Sanchez]

Hello,

I am trying to set a variable in an IF block, but it doesn't appear in
the resulting cache or makefile.  This is on Linux.  Note that when I
run cmake, the ${OSNAME} variable is printed, but the ${FOOBAR} variable
ends up blank.

Thanks,

Juan

IF (${OSNAME} STREQUAL Linux64)
  MESSAGE (${OSNAME})
  SET (FOOBAR -m64 -Wall -fPIC -I${PERLLIB} -I${PSTORE}/include)
ENDIF (${OSNAME} STREQUAL Linux64)

MESSAGE ( COMPILE_FLAGS ${FOOBAR})


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

[CMake] Re: set variable in if block

[Juan Sanchez]

My apologies, it turns out there was a syntax error, that was not fatal,
and not mentioned in the debug output.

Thanks,

Juan


Juan Sanchez wrote:
 Hello,
 
 I am trying to set a variable in an IF block, but it doesn't appear in
 the resulting cache or makefile.  This is on Linux.  Note that when I
 run cmake, the ${OSNAME} variable is printed, but the ${FOOBAR} variable
 ends up blank.
 
 Thanks,
 
 Juan
 
 IF (${OSNAME} STREQUAL Linux64)
   MESSAGE (${OSNAME})
   SET (FOOBAR -m64 -Wall -fPIC -I${PERLLIB} -I${PSTORE}/include)
 ENDIF (${OSNAME} STREQUAL Linux64)
 
 MESSAGE ( COMPILE_FLAGS ${FOOBAR})
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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

[CMake] object file target

[Juan Sanchez]

Is there a command for creating a .o target on Linux?  If I create my
own custom command for creating an object, the .o file is being
recompiled every time.  I need the dependency scanner to recognize when
a .cc file does not need to be compiled into a .o file.

This is what I have right now.  Every time I type make, the object file
gets recreated.

  ADD_CUSTOM_COMMAND(
OUTPUT  ${PSTUFF}.o
DEPENDS ${PSTUFF}.cc
COMMAND ${CMAKE_CXX_COMPILER}
ARGS ${MYFLAGS}
  )


Thanks,

Juan


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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