Re: [CMake] [DKIM: Failed] Troubles with ExternalProject_Add and PATCH_COMMAND

2019-07-18 Thread Marcel Loose
Hi Steven,

When you run patch manually, do you then supply the same absolute paths?
Looking at the patch file I noticed that it contains a relative path. So
maybe you should cd to
${CMAKE_BINARY_DIR}/boost/src/external_boost/project-config.jam before
running the patch command.

Cheers,
Marcel.

Op 18-07-19 om 17:29 schreef Steven Truppe:
>
> Hi everyone,
>
> i try to patch a file from an externalprojects with the PATCH_COMMAND.
>
> The patch file looks like:
>
> --- project-config.jam    2019-07-18 17:21:44.008695808 +0200
> +++ project-config.jam.tmp    2019-07-18 17:23:28.236474532 +0200
> @@ -18,7 +18,7 @@
>  import python ;
>  if ! [ python.configured ]
>  {
> -    using python : 2.7 : /usr ;
> +    using python : 3.7 : /usr ;
>  }
>  
>  path-constant ICU_PATH : /usr ;
>
> When i try to apply the patch manualy with patch originalfile <
> patchfile it's working, but when i try it with the externalproject_add
> command:
>
> if(WITH_LIB_BOOST)
>     message(STATUS "Build WITH_LIB_BOOST.")
>
>     set(LIB_BOOST_INC_PATH ${OUTPUT_PATH}/libs/boost/include/)
>     set(LIB_BOOST_LIB_PATH ${OUTPUT_PATH}/libs/boost/lib)
>     set(LIB_BOOST_DEPS external_boost)
>     set(LIB_BOOST_STATIC_LIBS boost_python27)
>  
>     ExternalProject_Add(external_boost
>         PREFIX ${CMAKE_BINARY_DIR}/boost
>         URL ${BOOST_URL}
>         DOWNLOAD_DIR ${CMAKE_BINARY_DIR}/boost
>         URL_HASH MD5=${BOOST_HASH}
>         PATCH_COMMAND /usr/bin/patch 
> ${CMAKE_BINARY_DIR}/boost/src/external_boost/project-config.jam < 
> ${CMAKE_SOURCE_DIR}/tools/patches/boost_python3.7.patch
>         CONFIGURE_COMMAND cd ${CMAKE_BINARY_DIR}/boost/src/external_boost/ &&
>                         ./bootstrap.sh --prefix=${OUTPUT_PATH}/libs/boost/ 
> --with-libraries=python
>         BUILD_COMMAND cd ${CMAKE_BINARY_DIR}/boost/src/external_boost/ &&
>                       ./b2
>         INSTALL_COMMAND cd ${CMAKE_BINARY_DIR}/boost/src/external_boost/ && 
> ./bjam && ./bjam install
>         INSTALL_DIR ${OUTPUT_PATH}/boost
>     )
>
> endif()
>
> But when running cmake i get the following output:
>
> patching file 
> /home/stuv/projects/programming/bsEdit/build/boost/src/external_boost/project-config.jam
> Hunk #1 FAILED at 18.
>
>
> I have no idea what i'm doing wrong here, i hope someone here can help
> me out.
>
>
> best regards,
>
> Steven Truppe
>
>
>
>
>

-- 

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] getting compiler's include paths

2019-07-18 Thread Robert Maynard
The history behind the makefile generator and the custom dependency
tracking logic was that it was written before
the majority of compilers offered a robust way to generate the list of
header dependencies.

As it stands now we want to remove all this custom dependency scanning
logic, not extend it to understand system headers
( As the naive approach would cause CMake to parse system headers, and
slow down even more ). Luckily, C++20 modules
also require us to drop the custom dependency scanning, so when we add
C++20 module support to the Makefile generator
this issue will be fixed as by product.

On Wed, Jul 3, 2019 at 10:51 AM Robert Maynard
 wrote:
>
> I completely forgot that the Makefiles based generators in CMake have
> a separate heuristic for determining system headers.
>
> If you use the Ninja generator I see the expected behavior:
> ~/W/t/nbuild $ sudo touch /usr/include/c++/7/array
> ~/W/t/nbuild $ ninja -d explain -v
> ninja explain: output test/CMakeFiles/ProjTest.dir/test.cpp.o older
> than most recent input /usr/include/c++/7/array (1562165327 vs
> 1562165329)
> ninja explain: test/CMakeFiles/ProjTest.dir/test.cpp.o is dirty
> ninja explain: test/ProjTest is dirty
> [1/2] /usr/bin/c++   -I../my_lib/include -std=gnu++1z -MD -MT
> test/CMakeFiles/ProjTest.dir/test.cpp.o -MF
> test/CMakeFiles/ProjTest.dir/test.cpp.o.d -o
> test/CMakeFiles/ProjTest.dir/test.cpp.o -c ../test/test.cpp
> [2/2] : && /usr/bin/c++ test/CMakeFiles/ProjTest.dir/test.cpp.o
> -o test/ProjTest   && :
>
>
> I will need to spend some more time figuring out the extra include
> caching logic for the Makefile based generators, and will report back.
>
> On Thu, Jun 27, 2019 at 8:59 AM jl forums  wrote:
> >
> > thanks for the anwer
> > quite not... I'm using cmake 3.14.2 (so, far away from 3.6) and have a 
> > look, in main.cpp, there is #include :
> >
> > $ find /usr/include/ -name filesystem
> > /usr/include/c++/5/experimental/filesystem
> > /usr/include/c++/7/experimental/filesystem
> > /usr/include/c++/8/filesystem
> > /usr/include/c++/8/experimental/filesystem
> > $ sudo touch /usr/include/c++/5/experimental/filesystem 
> > /usr/include/c++/7/experimental/filesystem /usr/include/c++/8/filesystem 
> > /usr/include/c++/8/experimental/filesystem
> > $ make
> > [100%] Built target FileSync
> > $ touch ../main.cxx
> > $ make
> > Scanning dependencies of target FileSync
> > [ 50%] Building CXX object CMakeFiles/FileSync.dir/main.cxx.o
> > [100%] Linking CXX executable FileSync
> > [100%] Built target FileSync
> >
> >
> > => cmake don't create "full include dependency" which IS a mistake 
> > updating system g++ can just assume the target is uptodate and in fact just 
> > create a broken build...
> >
> > in cmake cxx.includecache
> >
> > #IncludeRegexLine: ^[ ]*[#%][ ]*(include|import)[ ]*[<"]([^">]+)([">])
> > #IncludeRegexScan: ^.*$
> > #IncludeRegexComplain: ^$
> > #IncludeRegexTransform:
> > /home/orange/crypt/Devel/projets/FileSync/main.cxx
> > cstdio
> > -
> > io.h
> > -
> > fcntl.h
> > -
> > locale
> > -
> > clocale
> > -
> > fstream
> > -
> > iostream
> > -
> > filesystem
> > -
> >
> > $ /usr/bin/gcc-8 -M ../main.cxx
> > main.o: ../main.cxx /usr/x86_64-linux-gnu/include/stdc-predef.h \
> >  /usr/include/c++/8/cstdio \
> >  /usr/include/x86_64-linux-gnu/c++/8/bits/c++config.h \
> >  /usr/include/x86_64-linux-gnu/c++/8/bits/os_defines.h \
> >  /usr/x86_64-linux-gnu/include/features.h \
> >  /usr/x86_64-linux-gnu/include/sys/cdefs.h \
> >  /usr/x86_64-linux-gnu/include/bits/wordsize.h \
> >  /usr/x86_64-linux-gnu/include/bits/long-double.h \
> >  /usr/x86_64-linux-gnu/include/gnu/stubs.h \
> >  /usr/x86_64-linux-gnu/include/gnu/stubs-64.h \
> >  /usr/include/x86_64-linux-gnu/c++/8/bits/cpu_defines.h \
> >  /usr/x86_64-linux-gnu/include/stdio.h \
> >  /usr/x86_64-linux-gnu/include/bits/libc-header-start.h \
> >  /usr/lib/gcc/x86_64-linux-gnu/8/include/stddef.h \
> >  /usr/x86_64-linux-gnu/include/bits/types.h \
> >  /usr/x86_64-linux-gnu/include/bits/typesizes.h \
> >  /usr/x86_64-linux-gnu/include/bits/types/__FILE.h \
> >  /usr/x86_64-linux-gnu/include/bits/types/FILE.h \
> >  /usr/x86_64-linux-gnu/include/bits/libio.h \
> >  /usr/x86_64-linux-gnu/include/bits/_G_config.h \
> >  /usr/x86_64-linux-gnu/include/bits/types/__mbstate_t.h \
> >  /usr/lib/gcc/x86_64-linux-gnu/8/include/stdarg.h \
> >  /usr/x86_64-linux-gnu/include/bits/stdio_lim.h \
> >  /usr/x86_64-linux-gnu/include/bits/sys_errlist.h \
> >  /usr/include/c++/8/locale /usr/include/c++/8/bits/localefwd.h \
> >  /usr/include/x86_64-linux-gnu/c++/8/bits/c++locale.h \
> >  /usr/include/c++/8/clocale /usr/x86_64-linux-gnu/include/locale.h \
> >  /usr/x86_64-linux-gnu/include/bits/locale.h \
> >  /usr/x86_64-linux-gnu/include/bits/types/locale_t.h \
> >  /usr/x86_64-linux-gnu/include/bits/types/__locale_t.h \
> >  /usr/include/c++/8/iosfwd /usr/include/c++/8/bits/stringfwd.h \
> >  /usr/include/c++/8/bits/memoryfwd.h /usr/include/c++/8/bits/postypes.h \
> >

[CMake] Troubles with ExternalProject_Add and PATCH_COMMAND

2019-07-18 Thread Steven Truppe

Hi everyone,

i try to patch a file from an externalprojects with the PATCH_COMMAND.

The patch file looks like:

--- project-config.jam    2019-07-18 17:21:44.008695808 +0200
+++ project-config.jam.tmp    2019-07-18 17:23:28.236474532 +0200
@@ -18,7 +18,7 @@
 import python ;
 if ! [ python.configured ]
 {
-    using python : 2.7 : /usr ;
+    using python : 3.7 : /usr ;
 }

 path-constant ICU_PATH : /usr ;

When i try to apply the patch manualy with patch originalfile <
patchfile it's working, but when i try it with the externalproject_add
command:

if(WITH_LIB_BOOST)
    message(STATUS "Build WITH_LIB_BOOST.")

    set(LIB_BOOST_INC_PATH ${OUTPUT_PATH}/libs/boost/include/)
    set(LIB_BOOST_LIB_PATH ${OUTPUT_PATH}/libs/boost/lib)
    set(LIB_BOOST_DEPS external_boost)
    set(LIB_BOOST_STATIC_LIBS boost_python27)

    ExternalProject_Add(external_boost
        PREFIX ${CMAKE_BINARY_DIR}/boost
        URL ${BOOST_URL}
        DOWNLOAD_DIR ${CMAKE_BINARY_DIR}/boost
        URL_HASH MD5=${BOOST_HASH}
        PATCH_COMMAND /usr/bin/patch 
${CMAKE_BINARY_DIR}/boost/src/external_boost/project-config.jam < 
${CMAKE_SOURCE_DIR}/tools/patches/boost_python3.7.patch
        CONFIGURE_COMMAND cd ${CMAKE_BINARY_DIR}/boost/src/external_boost/ &&
                        ./bootstrap.sh --prefix=${OUTPUT_PATH}/libs/boost/ 
--with-libraries=python
        BUILD_COMMAND cd ${CMAKE_BINARY_DIR}/boost/src/external_boost/ &&
                      ./b2
        INSTALL_COMMAND cd ${CMAKE_BINARY_DIR}/boost/src/external_boost/ && ./bjam 
&& ./bjam install
        INSTALL_DIR ${OUTPUT_PATH}/boost
    )

endif()

But when running cmake i get the following output:

patching file 
/home/stuv/projects/programming/bsEdit/build/boost/src/external_boost/project-config.jam

Hunk #1 FAILED at 18.


I have no idea what i'm doing wrong here, i hope someone here can help
me out.


best regards,

Steven Truppe




-- 

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