View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0010346CMakeModulespublic2010-02-28 13:062010-09-26 08:24
ReporterAlex Neundorf 
Assigned ToDavid Cole 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in VersionCMake-2-8 
Summary0010346: externalproject_add() does not work with only SOURCE_DIR given
DescriptionIf I want externalproject() to use the sources from an existing directory, according to the documentation I need to set only SOURCE_DIR.
But when I do so, I get
"error: no download info for HwLoc -- please specify existing SOURCE_DIR or one of URL, CVS_REPOSITORY and CVS_MODULE, SVN_REPOSITORY or DOWNLOAD_COMMAND"

The attached patch adds an else() branch for the case that SOURCE_DIR is set.
In this branch also cmd is set, otherwise cmake complains.
Also, it would be nice if in this case the directory DOWNLOAD_DIRECTORY would not be created.

TagsNo tags attached.
Attached Filespatch file icon externalproject.patch [^] (748 bytes) 2010-02-28 13:06 [Show Content]

- Relationships Relation Graph ] Dependency Graph ]
has duplicate 0010448closedDavid Cole ExternalProject_Add does not work with existing SOURCE_DIR 

-  Notes
Alex Neundorf (developer)
2010-04-10 17:09

Dave, what do you think about the attached tiny patch ?
With the patch, if you already have a source dir, you can just specify it in externalproject_add() and don't have to explicitely set the DOWNLOAD_COMMAND empty.

If you think that's ok, I would commit it.

David Cole (manager)
2010-04-13 14:41

Please do *not* apply the attached patch, "externalproject.patch"!

The problem with the attached patch is that the variable "source_dir" is ALWAYS set, and the source directory "${source_dir}" ALWAYS exists, even if it has no content... because we actually create it at configure time, and at build time with make_directory and -E mkdir commands...

So, if we did take the attached patch, there would be no need for the else clause.

And people who do not specify anything will never see an error until build time.

But, really, the fix should be to see if there is a source_dir property set by the end user, as opposed to one that is set automatically by the logic in ExternalProject. The logic for determining this is a bit more complex... but I'll get to writing a fix eventaully.
Alex Neundorf (developer)
2010-04-13 15:10

Ok. If I find the time I'll have a look whether I can come up with a better patch.
If not, it's actually not a big deal.

David Cole (manager)
2010-06-09 18:43

I just pushed this commit to the 'next' branch:;a=commitdiff;h=cd3d60b8b5ae89b9c352b9ba022ae04ab97ea0e4 [^]

Please try it out if you get the chance and tell me if you see anything wrong with this approach.

David Cole (manager)
2010-06-18 17:08

The fix for this issue is included in CMake 2.8.2-rc2.
Alex Neundorf (developer)
2010-09-26 08:24

It was already resolved, close it.

- Issue History
Date Modified Username Field Change
2010-02-28 13:06 Alex Neundorf New Issue
2010-02-28 13:06 Alex Neundorf File Added: externalproject.patch
2010-02-28 13:06 Alex Neundorf Status new => assigned
2010-02-28 13:06 Alex Neundorf Assigned To => David Cole
2010-04-10 17:09 Alex Neundorf Note Added: 0020122
2010-04-10 17:09 Alex Neundorf Severity major => minor
2010-04-13 14:41 David Cole Note Added: 0020163
2010-04-13 15:10 Alex Neundorf Note Added: 0020166
2010-04-19 11:51 David Cole Relationship added has duplicate 0010448
2010-06-09 18:43 David Cole Note Added: 0020960
2010-06-18 17:08 David Cole Note Added: 0021093
2010-06-18 17:08 David Cole Status assigned => resolved
2010-06-18 17:08 David Cole Resolution open => fixed
2010-09-26 08:24 Alex Neundorf Note Added: 0022350
2010-09-26 08:24 Alex Neundorf Status resolved => closed
2010-09-26 08:24 Alex Neundorf Fixed in Version => CMake-2-8

Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker