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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Alexander Tarnopolsky
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
Reply | Threaded
Open this post in threaded view
|

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

Michael Wild
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

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

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

Alexander Tarnopolsky
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:[hidden email]]
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.


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: 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:[hidden email]]
> 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.
>
>

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

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

Alexander Tarnopolsky
Such a long path imposes several constrains/inconveniences:

1) It limits number of objects that could be passed to link command to
~1300 (which is OK with us for now).

2) It substantially increases the size and readability of the build log
files. (hence makes it difficult to debug build problems)

3) We use build procedures that glob for object files (for example in
order to clean orphan objects that are no longer listed in
CMakeLists.txt). We'll have to use more complex logic in those
procedures.

Kind Regards,
Alex Tarnopolsky

-----Original Message-----
From: Michael Wild [mailto:[hidden email]]
Sent: Monday, November 30, 2009 10:50 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>)?

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:[hidden email]]
> 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.
>
>

---------------------------------------------------------------------------------------------------------------
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