[CMake] Is there a way to omit relative path from the name of the comilation output file (<OBJECT>)?

[Michael Wild]

Is it only the messages printed to the screen that you're concerned  
with?

Michael


On 30. Nov, 2009, at 18:39 , Alexander Tarnopolsky wrote:

> Thanks for prompt response!
>
> The real reason for inclusion of those "external" sources is the  
> size of
> our projects.
>
> We have read-only "shared/public" workarea were all the sources  
> reside.
> The developer checks-out only the files that should be modified during
> his current task (his source files are complemented with "public"  
> files
> during the build).
>
> We try to avoid copying/duplication of a large number of files to
> developer's workarea (which takes time/bandwidth, requires frequent
> updates and raises chances for inconsistency).
>
> With the same rational we'd like to avoid copying of sources to
> ${CMAKE_BINARY_DIR}.
>
> Kind Regards,
> Alex Tarnopolsky
>
>
> -----Original Message-----
> From: Michael Wild [mailto:themiwi at gmail.com]
> Sent: Monday, November 30, 2009 6:47 PM
> To: Alexander Tarnopolsky
> Cc: CMake List
> Subject: Re: [CMake] Is there a way to omit relative path from the  
> name
> of the comilation output file (<OBJECT>)?
>
> Apart from me not liking this setup (those external sources should
> probably be a separate project and be compiled as a library which then
> is imported) you could use
> CONFIGURE_FILE(/long/path/to/file ${CMAKE_BINARY_DIR}/file COPYONLY)
> and then pass ${CMAKE_BINARY_DIR}/file to the add_executable/
> add_library calls. You could also wrap the latter commands in custom
> macros/functions to scan a list of source files for out-of-source
> sources and the automatically copy them to the build tree.
>
> Michael
>
> On 30. Nov, 2009, at 16:53 , Alexander Tarnopolsky wrote:
>
>> Dear CMake users list,
>>
>> In our build system we have to compile source files that reside out  
>> of
>> source/build tree. In some cases there are several hundreds of such
>> "external" sources in a project.
>>
>> Consider simplified CMakeLists.txt:
>> ===================================
>> Project (system)
>>
>> set(SOURCES
>> /users/gdadmin/PG41/project/src/library/system/AttachDebugger.cc
>> /users/gdadmin/PG41/project/src/library/system/CPUInfo.cc
>> DSOInfo.cc
>> DSOManip.cc
>> HelpControl.cc
>> LocateExe.cc
>> MksTemp.cc
>> PathManip.cc
>> PluginLoader.cc
>> ProcessAffinity.cc
>> RTTI.cc
>> Setenv.cc
>> ShellUtils.cc
>> Sleep.cc
>> SysTime.cc
>> TraceStack.cc
>> UserInfo.cc
>> VTControl.cc
>> Asm/CPUID_c.cc
>> )
>>
>> add_library (system SHARED ${SOURCES})
>> =======================================
>>
>> The compilation of the first source produces the following output
>> file:
>> "CMakeFiles/system.dir/users/gdadmin/PG41/project/src/library/system/
>> Att
>> achDebugger.cc.o"
>>
>> Imagine a link command where several hundreds of object files are
>> listed
>> with this relative path...
>>
>> Thus we are looking for a way to shorten the path. Ideally - we'd  
>> like
>> to generate compiled objects under the same flat-directory
>> regardless of
>> the source file location.
>>
>> I understand that ""CMakeFiles/system.dir" part of the relative path
>> to
>> object files cannot be changed - I hope we can handle this.
>>
>> But is there a way to change
>> "/users/gdadmin/PG41/project/src/library/system" part?
>>
>> I experimented with CMAKE_CXX_COMPILE_OBJECT rule-variable and tried
>> to
>> replace the <OBJECT> with something else, but apparently the
>> rule-command is invoked always when <OBJECT> file is missing,  
>> probably
>> the dependency between <OBJECT> and <SOURCE> drives the rule-command.
>>
>> Of course there is a possibility to compile objects by a custom
>> command
>> and to manage object's dependencies by a script etc.. However we  
>> don't
>> like to give up on cmake built-in rules for compilation and  
>> dependency
>> tracking.
>>
>> Thanks in advance for your help,
>> Kind Regards,
>> Alex Tarnopolsky
>>
> ------------------------------------------------------------------------
> ---------------------------------------
>> This e-mail, including any attached files, may contain confidential
>> and privileged information for the sole use of the intended
>> recipient. Any review, use, distribution, or disclosure by others is
>> strictly prohibited. If you are not the intended recipient (or
>> authorized to receive information for the intended recipient),
>> please contact the sender by reply e-mail and delete all copies of
>> this message.
>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
>
> ---------------------------------------------------------------------------------------------------------------
> This e-mail, including any attached files, may contain confidential  
> and privileged information for the sole use of the intended  
> recipient. Any review, use, distribution, or disclosure by others is  
> strictly prohibited. If you are not the intended recipient (or  
> authorized to receive information for the intended recipient),  
> please contact the sender by reply e-mail and delete all copies of  
> this message.
>
>