Skip to content

Conversation

@Klaim
Copy link
Member

@Klaim Klaim commented Oct 20, 2025

Description

  • removes spdlog from libmamba dependencies;
  • adds a new library libmamba-spdlog which provides the spdlog-based LogHandler for mamba;
  • libmambapy and mamba/micromamba now depends on libmamba-spdlog to keep using spdlog as a log handler;

For simplicity, libmamba-spdlog is a header-only library. This avoids many possible variations of libmamba usage to get in the way of easy packaging. As we always use spdlog as a header-only library and we just wrapps it, it shouldnt impact usage much. Also only end-user targets (usually executables) will need to decide which LogHandler to use so this header will probably only be compiled once.

Notes:

Type of Change

  • Bugfix
  • Feature / enhancement
  • CI / Documentation
  • Maintenance

Checklist

  • My code follows the general style and conventions of the codebase, ensuring consistency
  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • My changes generate no new warnings
  • I have run pre-commit run --all locally in the source folder and confirmed that there are no linter errors.
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing tests pass locally with my changes

@github-actions github-actions bot added the release::maintenance For PRs related to maintenance label Oct 20, 2025
Copy link
Member

@jjerphan jjerphan left a comment

Choose a reason for hiding this comment

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

I think that one could create a PR on mamba-feedstock with the patch to anticipate packaging changes.

@Klaim
Copy link
Member Author

Klaim commented Nov 25, 2025

I think that one could create a PR on mamba-feedstock with the patch to anticipate packaging changes.

I agree, I'll take a look there. I will probably need your help with details @jjerphan 🙏🏽

@jjerphan
Copy link
Member

We can iterate on conda-forge/mamba-feedstock#368.

get_target_property(type ${target} TYPE)
if(NOT ${type} STREQUAL "INTERFACE_LIBRARY")
target_compile_options("${target}" PRIVATE ${warnings})
endif()
Copy link
Member

Choose a reason for hiding this comment

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

What is the issue with adding warnings to an Interface library?

Copy link
Member Author

@Klaim Klaim Nov 27, 2025

Choose a reason for hiding this comment

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

PRIVATE cannot be used with target_compile_options when the target is INTERFACE_LIBRARY (header-only). (that triggers a cmake error, to be clear)

I fixed it by not adding the warnings because usually warnings flags should be set for the target having the translation units to compile these warnings with, that's why PRIVATE is used here to not pollute the flags for the user of the library. But because we have a header-only library, we don't have translation units. We never want to pollute the user build with flags added to headers they will include. In the case of header-only libraries, warnings should be set only on the test executables.

If we wanted to, we could change the PRIVATE to INTERFACE if the target is an interface library, but then we impose our warnings to all the code using these headers.

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for the explanation. I agree we should not impose our warnings to the user, so let's keep it as is.

@PACKAGE_INIT@

include("${CMAKE_CURRENT_LIST_DIR}/@[email protected]")
check_required_components("@PROJECT_NAME@")
Copy link
Member

Choose a reason for hiding this comment

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

This file should also contain calls to find_dependency for libmamba and spdlog

Copy link
Member

@jjerphan jjerphan left a comment

Choose a reason for hiding this comment

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

Thanks! Just minor nipicks.

this does not provide the necessary work to package libmamba-spdlog (next pr?);

What do you think of adding changes in this PR to be able to package libmamba-spdlog to test everything with conda-forge/mamba-feedstock#368?

option(BUILD_SHARED "Build shared libmamba library" OFF)
option(BUILD_STATIC "Build static libmamba library with static linkage to its dependencies" OFF)
option(BUILD_LIBMAMBA "Build libmamba library" OFF)
option(BUILD_LIBMAMBA_SPDLOG_TESTS "Build libmamba-spdlog library tests" OFF)
Copy link
Member

Choose a reason for hiding this comment

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

I think that we would need this to be able to distribute libmamba-spdlog independently.

Suggested change
option(BUILD_LIBMAMBA_SPDLOG_TESTS "Build libmamba-spdlog library tests" OFF)
option(BUILD_LIBMAMBA_SPDLOG "Build libmamba-spdlog library" OFF)
option(BUILD_LIBMAMBA_SPDLOG_TESTS "Build libmamba-spdlog library tests" OFF)

Copy link
Member Author

Choose a reason for hiding this comment

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

I initially had that but realized it made no sense in the context of mamba and libmambapy and also that library is header-only so it doesnt make sense to "build" it. But we can use it as en enable/disable thing, sure, in particular if it helps with packaging.

Comment on lines +7 to +8
#ifndef MAMBA_LOGGING_SPDLOG_HPP
#define MAMBA_LOGGING_SPDLOG_HPP
Copy link
Member

Choose a reason for hiding this comment

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

How about using?

Suggested change
#ifndef MAMBA_LOGGING_SPDLOG_HPP
#define MAMBA_LOGGING_SPDLOG_HPP
#pragma once

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm fine with it, although note that it is not the policy for libmamba/.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'll do it in a separate commit to remove the endif too

Copy link
Member

@JohanMabille JohanMabille Nov 27, 2025

Choose a reason for hiding this comment

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

I think we should keep the codebase homogeneous. If we decide to replace the inclusion guards with pragma once statements, that should be done for the whole codebase in a dedicated PR.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'll replace the pragma once in the impl header and we can change everything in that future pr

@Klaim
Copy link
Member Author

Klaim commented Nov 27, 2025

Thanks! Just minor nipicks.

this does not provide the necessary work to package libmamba-spdlog (next pr?);

What do you think of adding changes in this PR to be able to package libmamba-spdlog to test everything with conda-forge/mamba-feedstock#368?

We had a short discussion with @JohanMabille about that when I started, as stated in the pr description the goal was not to prepare for packaging.
But if the changes necessary are not too involved, I guess we can, I wouldnt mind as long as it doesnt add to the cmake noise.

Copy link
Member

@jjerphan jjerphan left a comment

Choose a reason for hiding this comment

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

OK, as you prefer; I think that we will need to have the packaging change in also if we have to make a release (are those significant?).

LGTM once the threads with Johan are resolved.

Klaim added a commit to Klaim/micromamba-feedstock that referenced this pull request Dec 2, 2025
Copy link
Member

@jjerphan jjerphan left a comment

Choose a reason for hiding this comment

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

One last suggestion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

release::maintenance For PRs related to maintenance

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants