Skip to content
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 5 additions & 6 deletions easybuild/easyconfigs/s/spdlog/spdlog-1.15.3-GCCcore-14.3.0.eb
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,7 @@ version = '1.15.3'

homepage = 'https://github.com/gabime/spdlog'
description = "Very fast, header-only/compiled, C++ logging library."

toolchain = {'name': 'GCCcore', 'version': '14.3.0'}
toolchainopts = {'pic': True}

Expand All @@ -17,15 +18,13 @@ builddependencies = [
('CMake', '4.0.3'),
]

_shared_configopts = " ".join([
"-DSPDLOG_BUILD_SHARED=ON",
"-DSPDLOG_BUILD_PIC=ON",
])
_base_configopts = ' -DSPDLOG_BUILD_TESTS=ON'
configopts = [f'{_base_configopts} -DSPDLOG_BUILD_SHARED={x}' for x in ('OFF', 'ON')]
Comment on lines 20 to 23
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if we want to remove SPDLOG_BUILD_PIC=ON

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is doing what we are already doing in the CMake EB when setting the fpic TC option to true

https://github.com/gabime/spdlog/blob/486b55554f11c9cccc913e11a87085b2a91f706f/CMakeLists.txt#L149-L151

But i would still leave it there to ensure that we follow what the source CMake dictates in case they add more stuff in the future

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was not aware of the other PR so mine was based on a different 'template' and thus, I did not remove it, I simply never added it. I have put that back, thanks for finding this!


configopts = ["", _shared_configopts]
runtest = 'test'

sanity_check_paths = {
'files': ['include/%(name)s/%(name)s.h', 'lib/lib%(name)s.a', f'lib/lib%(name)s.{SHLIB_EXT}'],
'files': [f'include/{name}/{name}.h', 'lib/libspdlog.a', 'lib/libspdlog.%s' % SHLIB_EXT],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
'files': [f'include/{name}/{name}.h', 'lib/libspdlog.a', 'lib/libspdlog.%s' % SHLIB_EXT],
'files': ['include/%(name)s/%(name)s.h', 'lib/lib%(name)s.a', f'lib/lib%(name)s.{SHLIB_EXT}'],
  • %(name)s are EB templates. I do not expect it to ever be different from name in the EC but i would keep it as such w.r.t other ECs
  • SHLIB_EXT is also an EB variable that will be injected in the EC. with python linting it appears undefined but it will be replaced when the EC is loaded

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding was the %(foo)s is better replaced with f'{foo}' as it is easier to read. Did I get that wrong?

Copy link
Contributor

@Crivella Crivella Oct 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are not equivalent. What i was referring to is the % used to place SHLIB_EXT in the string.

%(name)s is not a string formatting but an EB template that is replaced by EB when reading the EasyConfig.

The ones under https://docs.easybuild.io/version-specific/easyconfig-templates/#template-namesvalues-as-set-in-easyconfig are probably the only trivial ones that will be equivalent to the value in the EC

EDIT: for context we already have some {name} in EB but templates are the majority

(easybuild-dev) crivella@crivella-desktop:~/Documents/GIT/easybuild-easyconfigs $ grep -l -R '{name}' * | wc -l
124
(easybuild-dev) crivella@crivella-desktop:~/Documents/GIT/easybuild-easyconfigs $ grep -l -R '%(name)s' * | wc -l
2249

'dirs': ['lib64/cmake', 'lib64/pkgconfig'],
Comment on lines 27 to 29
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would keep consistent usage of f-strings without re-introducing old % formatting.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I done my PR without being aware of what you already done @Crivella . So that is why I had already the f-string for the bit I knew how to do it, but I was not sure how to do it for the SHLIB_EXT bit. So now that is consistent, thanks fo your help.

}

Expand Down