[CMake] [CMake 0012322]: Ability to add source files to target created with ExternalProject

Yuri Timenkov yuri at timenkov.ru
Fri Aug 12 11:45:35 EDT 2011


It is, if you use it for 3rd-party libraries.

But some people (including me :)) may use it to build different parts of
single project with different compilers (I have one library which should be
built with VC6 and the rest of the project with VC2010, but I change code in
each place with same frequency).

In this case it is far from black box. But I completely agree, that this is
discussion about "typical usage". I just was very happy when I got chance to
significantly simplify and make even more user-friendly our build procedure
:).

On Fri, Aug 12, 2011 at 7:29 PM, David Cole <david.cole at kitware.com> wrote:

> The typical ExternalProject is a bit of a black-box to the containing
> project, and a list of sources is something most users will not
> have... That's another reason why I am skeptical as to the usefulness
> of this feature to the general ExternalProject consumer.
>
>
> On Fri, Aug 12, 2011 at 11:24 AM, Yuri Timenkov <yuri at timenkov.ru> wrote:
> > Ok, I'll double-check this next monday. That's why I was confused.
> >
> > On the second thought if you have a list of sources you can add them as
> > dependencies in addition to build rule, then step will be re-run as
> > expected. May be it's my case.
> >
> > Anyways I need to do some more investigation.
> >
> > Best wishes,
> > Yuri
> >
> > On Aug 12, 2011 6:54 PM, "David Cole" <david.cole at kitware.com> wrote:
> >> You can re-open the issue if you would like to have more discussion
> there.
> >>
> >> The build step does not always re-run. If you have an "update" step
> >> before the build step, then the update step always re-runs, and the
> >> build step after it, but many external projects do not have an update
> >> step, or anything else that "always" forces a build when there's a
> >> "Build Solution" executed on the containing project. (If it does, then
> >> that's a bug, because it's only supposed to re-execute steps that
> >> *need* to be re-executed.)
> >>
> >>
> >> Thanks,
> >> David
> >>
> >>
> >> On Fri, Aug 12, 2011 at 10:46 AM, Yuri Timenkov <yuri at timenkov.ru>
> wrote:
> >>> Hello David,
> >>> It seems that I can't add notes to closed bug, so I ask you directly.
> >>> I don't quite understand what kind of automatic dependencies you're
> >>> talking
> >>> about.
> >>> If I change file in this way and do "build solution" cmake will
> >>> automatically launch build for external project. IIRC it always
> executes
> >>> build when I build solution.
> >>> As I said, for my local purposes I can use modified
> ExternalProject.cmake
> >>> file, but I thought such feature might be useful for others.
> >>>
> >>> On Fri, Aug 12, 2011 at 5:24 PM, Mantis Bug Tracker
> >>> <mantis at public.kitware.com> wrote:
> >>>>
> >>>> A NOTE has been added to this issue.
> >>>> ======================================================================
> >>>> http://public.kitware.com/Bug/view.php?id=12322
> >>>> ======================================================================
> >>>> Reported By:                Yuri
> >>>> Assigned To:                David Cole
> >>>> ======================================================================
> >>>> Project:                    CMake
> >>>> Issue ID:                   12322
> >>>> Category:                   CMake
> >>>> Reproducibility:            always
> >>>> Severity:                   tweak
> >>>> Priority:                   normal
> >>>> Status:                     resolved
> >>>> Resolution:                 won't fix
> >>>> Fixed in Version:           CMake 2.8.6
> >>>> ======================================================================
> >>>> Date Submitted:             2011-07-08 05:27 EDT
> >>>> Last Modified:              2011-08-12 09:24 EDT
> >>>> ======================================================================
> >>>> Summary:                    Ability to add source files to target
> >>>> created
> >>>> with
> >>>> ExternalProject
> >>>> Description:
> >>>> In my scenario I have part of project which should be built with
> >>>> different
> >>>> toolset (Main project is built with VC2010, and some legacy libraries
> >>>> with
> >>>> VC6
> >>>> and VS2005).
> >>>> Basically nested project contains
> >>>> set(Proj_SRCS src1.cpp src2.cpp...)
> >>>> add_library(Proj MODULE ${Proj_SRCS})
> >>>>
> >>>> So set() command may be moved into separate file which in turn could
> be
> >>>> included
> >>>> into main project. So I want to see them there to edit in IDE, but not
> >>>> compile.
> >>>>
> >>>> The only possibility to add files to custom target - is specify
> SOURCES
> >>>> in
> >>>> add_custom_target command (It's impossible to call
> cmTarget::AddSources
> >>>> from
> >>>> outside). However, ExternalProject_Add macro doesn't add any sources.
> >>>>
> >>>> Moreover, there is a kind of chicken-and-egg problem: all arguments
> are
> >>>> parsed
> >>>> and set as property on target. But you can't set property while there
> is
> >>>> no
> >>>> target.
> >>>>
> >>>> So as quick work-around I made private copy of ExternalProject.cmake
> and
> >>>> pass
> >>>> sources as directory property.
> >>>>
> >>>> So I'm asking for ideas how to properly implement this feature: modify
> >>>> somehow
> >>>> parameters parsing in ExternalProject, or may be introduce command
> which
> >>>> allows
> >>>> adding new sources to existing targets (I'm not sure if this will
> work,
> >>>> but for
> >>>> me it sounds like target_link_libraries command).
> >>>> ======================================================================
> >>>>
> >>>> ----------------------------------------------------------------------
> >>>>  (0027196) David Cole (manager) - 2011-08-12 09:23
> >>>>  http://public.kitware.com/Bug/view.php?id=12322#c27196
> >>>> ----------------------------------------------------------------------
> >>>> I don't think we should do this.
> >>>>
> >>>> If we allow source files from external projects to be added directly
> to
> >>>> the IDE
> >>>> representations of the external projects in the containing project,
> then
> >>>> people
> >>>> will expect the dependencies to work correctly automatically...
> >>>>
> >>>> The dependencies will not work automatically. You will have to
> >>>> forcefully
> >>>> trigger an incremental rebuild of the external project on *any* build
> of
> >>>> the
> >>>> containing project, and then hope that its build system appropriately
> >>>> picks up
> >>>> only the incremental build changes necessary.
> >>>>
> >>>> I view this as fragile, and would not like to see it go in CMake
> unless
> >>>> it
> >>>> can
> >>>> be made robust, and shown to work automatically and as developers
> would
> >>>> expect
> >>>> in the vast majority of use cases.
> >>>>
> >>>> ----------------------------------------------------------------------
> >>>>  (0027197) David Cole (manager) - 2011-08-12 09:24
> >>>>  http://public.kitware.com/Bug/view.php?id=12322#c27197
> >>>> ----------------------------------------------------------------------
> >>>> If you need more help on this issue/topic, please send email to the
> >>>> CMake
> >>>> users
> >>>> list asking for advice there. There's a much wider readership of the
> >>>> mailing
> >>>> list than there is of the bug database.
> >>>>
> >>>> Issue History
> >>>> Date Modified    Username       Field                    Change
> >>>> ======================================================================
> >>>> 2011-07-08 05:27 Yuri           New Issue
> >>>> 2011-08-12 09:19 David Cole     Assigned To               => David
> Cole
> >>>> 2011-08-12 09:19 David Cole     Status                   new =>
> assigned
> >>>> 2011-08-12 09:23 David Cole     Note Added: 0027196
> >>>> 2011-08-12 09:23 David Cole     Status                   assigned =>
> >>>> resolved
> >>>> 2011-08-12 09:23 David Cole     Fixed in Version          => CMake
> 2.8.6
> >>>> 2011-08-12 09:23 David Cole     Resolution               open => won't
> >>>> fix
> >>>> 2011-08-12 09:24 David Cole     Note Added: 0027197
> >>>> ======================================================================
> >>>>
> >>>
> >>>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110812/26c380c5/attachment-0001.htm>


More information about the CMake mailing list