Skip to content

Conversation

LecrisUT
Copy link
Collaborator

@eirrgang sorry it took so long to get to this, but this should give you a more direct way to hook your cache-file as needed

@eirrgang
Copy link
Contributor

@eirrgang sorry it took so long to get to this, but this should give you a more direct way to hook your cache-file as needed

Sorry I missed the call this morning. Thanks for the help!

self.config.init_cache(cache_config)
cache_file_args = []
if self.settings.cmake.cache_file:
cache_file_args.append(f"-C{self.settings.cmake.cache_file}")
Copy link
Contributor

Choose a reason for hiding this comment

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

It would be good to test this, especially on Windows, to make sure that there isn't anything weird with path separators or escape characters. My Windows test machines are down right now, but I can probably help next week, if needed.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Good point I will try to add it. It shouldn't be any issue because we use Path in other parts as well without special handling (build-dir or source-dir), so that part should be fine (or we need to fix it in various places).

What I want to be covered though is the order of these flags and that those are predictable.

self.config.configure(
defines=cmake_defines,
cmake_args=[*self.get_cmake_args(), *configure_args],
cmake_args=[
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we have a note for the record somewhere? The initial cache file generated by scikit-build-core will be added to the end of the argument list, or the beginning? Do we expect the cache files to be processed sequentially? The AIs I ask disagree on how CMake handles multiple -C arguments.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It would be after the first -C that we add, but otherwise the order is a bit ill defined, I'll try to do some troubleshooting to see how -D flags impact it and if we need to reorder it.

But on that note, should this be a single option or a list of cache files?

Copy link
Contributor

Choose a reason for hiding this comment

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

Oof. Well, I guess it wouldn't be too hard to accept a sequence, but I don't personally need it. I guess the processing would be similar to cmake.define, so it wouldn't be unusual or surprising for users or developers.

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 am open to either approach. It's just that this decision needs to be definite so that we don't change the schema afterwards. We ave cmake.args for more free-style args if needed

Copy link
Contributor

Choose a reason for hiding this comment

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

Since cmake accepts multiple -C arguments, it would seem more correct to accept a list. I can't think of a good reason not to accept a list other than the effort and extra burden of support (documentation, test coverage, ...)

@henryiii
Copy link
Collaborator

What's wrong with passing -C? I'd like to focus on things that can't be done, not adding a second way to do things that are already supported. Is the order different, for example?

@LecrisUT
Copy link
Collaborator Author

What's wrong with passing -C? I'd like to focus on things that can't be done, not adding a second way to do things that are already supported. Is the order different, for example?

Mainly 2 usages:

  • Allow to be used with override and templating (I guess we did not add it to templating though)
  • Guarantee the ordering. I need to add the test to confirm how the ordering differs in relation to the InitCache, although if it always is at the end of it, this issue is mute.

@eirrgang
Copy link
Contributor

What's wrong with passing -C? I'd like to focus on things that can't be done, not adding a second way to do things that are already supported. Is the order different, for example?

For the record, I have added -C via CMAKE_ARGS in several projects with success. But I'm never sure whether I'm breaking current or future assumptions in scikit-build-core's internal machinery.

It might be that the integration tests for this issue are more important than the feature, now that https://github.com/orgs/scikit-build/discussions/1154#top is on record (even if not particularly google-able yet).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants