MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015118CMakeCMakepublic2014-08-30 00:492016-06-10 14:31
ReporterUmar Arshad 
Assigned ToDaniele E. Domenichelli 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformApple MacOSOS XOS Version10.4.10
Product VersionCMake 3.0 
Target VersionFixed in Version 
Summary0015118: ExternalProject_Add SOURCE_DIR field overrides DOWNLOAD_DIR field
DescriptionSetting the SOURCE_DIR field forces the download of a repository to that directory instead of the DOWNLOAD_DIR directory. This seems counter to what the documentation suggest since the SOURCE_DIR field is under the configuration section. This makes it difficult to add projects who's CMakeLists.txt files are not in the root folder of the repository (i.e. clBLAS)

DOWNLOAD_DIR should be where the project is downloaded/cloned
SOURCE_DIR should be the location of the CMakeLists.txt file
Steps To Reproduce# Set default ExternalProject root directory
set_directory_properties(PROPERTIES EP_PREFIX ${CMAKE_BINARY_DIR}/third_party)

ExternalProject_Add(
    clBlas
    GIT_REPOSITORY ssh://git@github.com/clMathLibraries/clBLAS.git [^]
    GIT_TAG "v2.2"
    TIMEOUT 10
    DOWNLOAD_DIR ${CMAKE_BINARY_DIR}/third_party/src/clBlas
    SOURCE_DIR ${CMAKE_BINARY_DIR}/third_party/src/clBlas/src
    CMAKE_ARGS -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
                -DCMAKE_ARCHIVE_OUTPUT_DIRECTORY_DEBUG:PATH=DebugLibs
                -DCMAKE_ARCHIVE_OUTPUT_DIRECTORY_RELEASE:PATH=ReleaseLibs
                -DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
                -DCMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS})
Additional Information
TagsNo tags attached.
Relationships
Attached Files? BuildCLBLAS.cmake (1,244) 2014-08-30 00:49
https://public.kitware.com/Bug/file/5238/BuildCLBLAS.cmake
Issue History
Date ModifiedUsernameFieldChange
2014-08-30 00:49Umar ArshadNew Issue
2014-08-30 00:49Umar ArshadFile Added: BuildCLBLAS.cmake
2014-09-02 15:28Brad KingNote Added: 0036703
2014-09-02 15:49Umar ArshadNote Added: 0036704
2014-09-02 16:30Daniele E. DomenichelliNote Added: 0036705
2014-09-02 16:41David ColeNote Added: 0036706
2014-09-03 09:50Brad KingAssigned To => Daniele E. Domenichelli
2014-09-03 09:50Brad KingStatusnew => assigned
2014-09-03 09:54Brad KingNote Added: 0036711
2014-09-03 10:06David ColeNote Added: 0036713
2014-09-03 10:15Brad KingNote Added: 0036714
2014-09-03 11:11David ColeNote Added: 0036721
2014-09-08 06:27Daniele E. DomenichelliNote Added: 0036740
2014-09-17 06:40Daniele E. DomenichelliNote Added: 0036819
2014-09-17 07:12David ColeNote Added: 0036820
2016-06-10 14:29Kitware RobotNote Added: 0042616
2016-06-10 14:29Kitware RobotStatusassigned => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0036703)
Brad King   
2014-09-02 15:28   
FWIW, the current behavior is as intended. The DOWNLOAD_DIR is just a staging directory for source tarballs. The SOURCE_DIR is always the top of the source tree, whether it is pre-populated, generated by extraction of a (downloaded) tarball, or generated by checkout from version control. The documentation could be clarified on this point.

You could specify a full CONFIGURE_COMMAND that spells out the full CMake command-line explicitly so the custom source directory can be specified.

> projects who's CMakeLists.txt files are not in the root folder

Perhaps there should be a SOURCE_SUBDIR option to specify a location underneath SOURCE_DIR to be treated as the top of the source tree for purposes of the configure step.
(0036704)
Umar Arshad   
2014-09-02 15:49   
I think the SOURCE_SUBDIR directory would work. The documentation should list the SOURCE_DIR under the Download step instead of the Configure step. I assumed SOURCE_DIR was the location of the CMakeList.txt as CMake defines CMAKE_SOURCE_DIR as the location of that file.

I ended up using CONFIGURE_COMMAND in my project, but I wanted to bring this issue up with you guys.
(0036705)
Daniele E. Domenichelli   
2014-09-02 16:30   
+1 for the SOURCE_SUBDIR, I have the same issue, at the moment I solved it by re-implementing all the commands.
I can work on this next week if nobody wants to do it, it shouldn't be hard to implement.
(0036706)
David Cole   
2014-09-02 16:41   
-1 for SOURCE_SUBDIR

SOURCE_DIR should be defined as the location of the top level CMakeLists.txt file. (to match CMAKE_SOURCE_DIR in a "normal" non-ExternalProject CMake invocation)

The problem is that SOURCE_DIR is used as both the location of the source tree (top level CMakeLists.txt file), *and* as the default place to extract downloaded tarballs or to put repo checkout results, making the assumption that the top level CMakeLists file is in the top level of the extracted tarball or repo...

I would prefer to see the current "download" be separated into two phases finally: download and extract. Then... this new parameter would naturally be named EXTRACT_DIR, (where tarball extraction, and repo checkouts would occur), and then SOURCE_DIR could point down inside the EXTRACT_DIR.

But..... I don't have time to contribute such a change at the moment, and will be happy with whatever anybody else is able to contribute.
(0036711)
Brad King   
2014-09-03 09:54   
Re 0015118:0036705: Thanks for volunteering to work on this.

Re 0015118:0036706: IIRC the SOURCE_DIR is also used as the directory for the Update step, and is the root version-controlled source directory. The proposed EXTRACT_DIR would supersede SOURCE_DIR for that role too. Anybody have an idea for a more general name than "EXTRACT_DIR"?
(0036713)
David Cole   
2014-09-03 10:06   
Possible other names: CONFIGURE_SOURCE_DIR, CONFIGURE_DIR, CMAKELISTS_DIR

Naming is always the hardest thing...
(0036714)
Brad King   
2014-09-03 10:15   
Re 0015118:0036713: Okay, so SOURCE_DIR would then remain the top version-controlled or tarball-extracted directory, and CONFIGURE_SOURCE_DIR would be the directory containing the configure script or top CMakeLists.txt file?
(0036721)
David Cole   
2014-09-03 11:11   
Re 0015118:0036714: yeah... but then that still violates my original objection that SOURCE_DIR should be analogous to a non-EP CMAKE_SOURCE_DIR... so I don't know.

None of these ideas seem satisfactory yet, for me, at the moment.
(0036740)
Daniele E. Domenichelli   
2014-09-08 06:27   
Could it be a relative path that will be appended to both SOURCE_DIR and BUILD_DIR? In this way one could also use this argument to share a version-controlled source directory containing several projects between different external projects.

The big problem would be the "TAG" though, if tags are different this could cause issues. Maybe it could be a list of directories?
(0036819)
Daniele E. Domenichelli   
2014-09-17 06:40   
Bump. I can work on this, but I'm not sure what to implement...
(0036820)
David Cole   
2014-09-17 07:12   
First: I would vote for *not* changing ExternalProject at all in this case, and telling people to customize CONFIGURE_COMMAND when this happens.

But: if you really really think a change like this is commonly needed, i.e., *most* people have to customize CONFIGURE_COMMAND because this happens so much, then I would vote for naming the new parameter CONFIGURE_SOURCE_DIR.
(0042616)
Kitware Robot   
2016-06-10 14:29   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.