#8129: Build UMD with CMake #9064
Conversation
joelsmithTT
requested review from
tt-rkim,
vtangTT and
TT-billteng
as code owners
joelsmithTT
force-pushed
the
joelsmith/umd-cmake
branch
from
4f1804c
to
977f4b0
Compare
|
Running post commit CI |
CMakeLists.txt
Outdated
| # Build umd_device | ||
| include(${CMAKE_CURRENT_SOURCE_DIR}/cmake/umd_device.cmake) | ||
|
|
||
| add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/tt_metal/third_party/umd) |
There was a problem hiding this comment.
can we add UMD via ExternalProject ? This avoids any potential namespace pollution
There was a problem hiding this comment.
Can you help me understand the problem you want to avoid with this?
I often edit code in tt_metal/third_party/umd and want the build to react appropriately in this situation.
There was a problem hiding this comment.
Could we make this behaviour opt in with a -D option at cmake first execution time?
There was a problem hiding this comment.
https://inhzus.io/posts/2023-12-01-cmake-external-project/#intro
you can test with add_subdirectory, but switch to ExternalProject_Add when you check in
|
I noticed that Metal no longer uses system-installed boost, but relies on a package manager. The current UMD CMakeLists.txt doesn't bother to It seems like we have a few options here:
My preference is for UMD to remain simple to build in a standalone manner. Any thoughts? |
Are you saying that you don't want to add
You could adapt CPM also in UMD :). This could work if you plan on removing Makefile support. |
joelsmithTT
force-pushed
the
joelsmith/umd-cmake
branch
from
977f4b0
to
abb7b5e
Compare
|
I think there's a simpler way to do this that gives Metal more control over the way UMD is built. Please see #9349 |
| target_link_libraries(tt_metal PUBLIC device metal_common_libs) | ||
| add_dependencies(tt_metal umd_device) | ||
|
|
||
| target_link_libraries(tt_metal PUBLIC compiler_flags linker_flags metal_header_directories yaml-cpp $<$<BOOL:$ENV{ENABLE_TRACY}>:TracyClient>) # linker_flags = -rdynamic if tracy enabled | ||
| target_link_directories(tt_metal PUBLIC ${CMAKE_BINARY_DIR}/lib) # required so tt_metal can find device library |
There was a problem hiding this comment.
If you link to umd_device instead of device I think you can get rid of this target_link_directories? Not sure if the ExternalAdd_Project affects this?
No description provided.