Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The build writes into the source directory #249

Closed
reddwarf69 opened this issue Jun 27, 2019 · 6 comments
Closed

The build writes into the source directory #249

reddwarf69 opened this issue Jun 27, 2019 · 6 comments

Comments

@reddwarf69
Copy link
Contributor

During the build doctest/doctest.h is generated into CMAKE_CURRENT_SOURCE_DIR, which makes it fail if the directory is read-only.

@onqtam
Copy link
Member

onqtam commented Jun 28, 2019

I'll look into this as soon as I can.

@onqtam
Copy link
Member

onqtam commented Aug 12, 2019

Well this is a pretty obscure problem... not sure if anything should (or could) be done about it. When in CMake the project is used as a subdirectory the command which assembles the doctest.h header doesn't run either, and the header is committed in it's assembled form anyway.

I'm closing this for now - if there are any ideas by anyone which don't require substantial changes I could incorporate something in the future.

@onqtam onqtam closed this as completed Aug 12, 2019
@reddwarf69
Copy link
Contributor Author

What exactly are the requirements of a solution?

  • There is a need for the git repository to contain an up to date copy of doctest/doctest.h for it to be easily usable as a submodule
  • There is a need to not write in CMAKE_CURRENT_SOURCE_DIR to support build environments where that's read-only.

Those requirements are not incompatible. Committers can always manually copy the file from CMAKE_BINARY_DIR into CMAKE_SOURCE_DIR before doing a commit. But "manually" is a dirty dirty word which always causes problems. You still need to manually do git add doctest/doctest.h even as it is right now, though. So... what exactly is your workflow?

@onqtam
Copy link
Member

onqtam commented Aug 13, 2019

I simply do a build which always assembles the single header (the command is here: https://github.com/onqtam/doctest/blob/2.3.4/CMakeLists.txt#L30) and then I git add . everything (after inspecting git status). This way the 2 headers and the final single header are never out of sync and there is no special and separate script which has to be executed. In the case of Catch2 the single header is regenerated only for releases and I'd like to have it always up-to-date.

That custom command is there only if(CMAKE_CURRENT_SOURCE_DIR STREQUAL CMAKE_SOURCE_DIR) so if you add doctest as a subdirectory using CMake's add_subdirectory() that shouldn't be a problem.

What is your use case? Why would you checkout doctest, not use it as a subproject and want to build the tests locally in a read-only place?

@reddwarf69
Copy link
Contributor Author

We have lots of small projects using doctest. So instead of adding it as a submodule to all of them we "build" it separately and then make it a "dependency" of those projects. We do that with lots of libraries (some of them not so simple to use as submodules) using a custom packaging system. Whenever we want to update doctest we only have to do it from one place (you could well argue that each project should stay with the version of doctest it has been tested against, but we don't).
Then our build system uses Docker and makes the source directories read-only. Mainly because these packages also need to build in third-party clients environments and we have found some of them making the source directories read-only.

At the end of the day it's not a big deal to us. We simply have added a step in the packaging recipe to first copy the sources into the build directory, which is obviously not read-only. So don't worry about it.

@onqtam
Copy link
Member

onqtam commented Aug 13, 2019

you could also skip the build process since it's just a header and trust the release engineering and CI of doctest :D

kidding. Well good to know that this is a potential issue. I'll leave it closed for now but if anyone else stumbles upon this it could be reopened.

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

No branches or pull requests

2 participants