# Best way to have a library package install a main.cpp and run add\_executable in context of user project when it calls my CMake function?
**URL:** https://discourse.cmake.org/t/best-way-to-have-a-library-package-install-a-main-cpp-and-run-add-executable-in-context-of-user-project-when-it-calls-my-cmake-function/11200
**Category:** Code
**Created:** [July 9, 2024, 4:00am UTC](https://discourse.cmake.org/t/best-way-to-have-a-library-package-install-a-main-cpp-and-run-add-executable-in-context-of-user-project-when-it-calls-my-cmake-function/11200 "2024-07-09T04:00:25Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Dennis\_Ferron](https://discourse.cmake.org/u/Dennis_Ferron)
#### Post date: [July 9, 2024, 4:00am UTC](https://discourse.cmake.org/t/best-way-to-have-a-library-package-install-a-main-cpp-and-run-add-executable-in-context-of-user-project-when-it-calls-my-cmake-function/11200/1 "2024-07-09T04:00:25Z")
The ANTLR4 parser project provides a TestRig (Java) class which helps you debug your grammar, but running it from CMake via add\_custom\_command (or similar) only runs it at configure or build time. To run a command from the CLion IDE’s Debug/Run menu, it has to be an actual (C++) executable target. So, I wrote a main.cpp that just issues a system call to load Java.exe and run the TestRig class from the ANTLR4 jar with appropriate arguments. This works; I call it test-rig-runner.
Now, I would like to provide this functionality conveniently via a vcpkg port. When I include the test-rig-runner executable built in the context of the port, vcpkg complains there should not be anything in the /bin folder for a static build. Someone on the vcpkg Discussions page said it could go in /tools, instead. However I’m not sure it (in /bin or /tools) will show up this way as a runnable target in the CLion IDE. I think it has to be an add\_executable in the context of the user project (not in the context of the port).
(When I say user project I mean the one importing the port and consuming the package.)
ANTLR4 itself provides a package, “antlr4-generator”, which provides a convenience function for generating the parser. It was through looking at that project’s code that I learned I need to put my CMake function into my cmake/\*-config.cmake.in file to get it to show up in the user project as a callable function. I assume if I put add\_executable in this function then when called from the user project that add\_executable will be in the context of the user project.
I haven’t tried that yet because I got tripped up thinking about where to put my test-rig-runner-main.cpp file. Obviously I can’t (I think?) reference it as simply as an add\_executable in the same source tree as its called. I would (I think?) have to use install(FILES …) on it, but then install to what subdirectory? To /include? To current binary directory? Maybe I could write the file from scratch (from a string) using file(WRITE).
- Or -
Is this just a bad idea in general? That is, is my goal here not really the best way to do this in CMake and packages? For example, I could provide 90% of the functionality as a library, and then make the user project explicitly do their own add\_executable & target\_add\_library. There’s actually still a question there what to do about the main.cpp, though because there’s three options:
1. User has their own int main and calls my library explicitly.
2. My library defines an int main for the user executable
3. My library provides a main.cpp file the user project add\_executable could reference.
Option 1 is the least astonishment. It’s also the most work for the user.
Option 2 is kinda what SDL2 does (defining it’s own main), and I hate SDL2 for doing that. Also, did I read somewhere add\_executable need at least one source file provided?
Option 3 begs the question, again, where to install a .cpp file for the user to use.
---
### Author:  [@retif](https://discourse.cmake.org/u/retif)
#### Post date: [July 9, 2024, 6:41am UTC](https://discourse.cmake.org/t/best-way-to-have-a-library-package-install-a-main-cpp-and-run-add-executable-in-context-of-user-project-when-it-calls-my-cmake-function/11200/2 "2024-07-09T06:41:00Z")
I had a similar case just recently, so I can comment a bit on some of your points (_not the major one though_).
> Someone on the vcpkg Discussions page said it could go in /tools
Yes, that’s the recommendation/policy, as far as a know. So it would be something [like this](https://github.com/retifrav/vcpkg-registry/blob/e4c4ce170133eb29f4aaca44cb4668f448fcf587/ports/sqlite/portfile.cmake#L84-L91):
```auto
vcpkg_copy_tools(TOOL_NAMES sometool AUTO_CLEAN)
```
> I would (I think?) have to use install(FILES …) on it, but then install to what subdirectory?
> where to install a .cpp file for the user to use
In my case I needed to distribute an additional source file of SQLite, and for now I [decided](https://github.com/retifrav/vcpkg-registry/blob/e4c4ce170133eb29f4aaca44cb4668f448fcf587/ports/sqlite/portfile.cmake#L95-L114) to just put it into `./share/sqlite3/etc/`:
```auto
file(
INSTALL "/path/to/memvfs.c"
DESTINATION "${CURRENT_PACKAGES_DIR}/share/sqlite3/etc"
)
```
And then in consuming projects I can use it like this (_assuming that dependencies are resolved with vcpkg_):
```auto
add_library(something) # add_executable(something)
target_sources(something
PRIVATE
"${VCPKG_INSTALLED_DIR}/${VCPKG_TARGET_TRIPLET}/share/sqlite3/etc/memvfs.c"
# some other sources
)
```
From what I know, there is no policy for source files installation paths, so I reckon any path would be good, just need to make sure that consuming projects know where it is.
---
### Author:  [@Dennis\_Ferron](https://discourse.cmake.org/u/Dennis_Ferron)
#### Post date: [July 9, 2024, 11:47pm UTC](https://discourse.cmake.org/t/best-way-to-have-a-library-package-install-a-main-cpp-and-run-add-executable-in-context-of-user-project-when-it-calls-my-cmake-function/11200/3 "2024-07-09T23:47:32Z")
Oh, hey, I recognize that user icon. You wrote the blog post which I keep revisiting as I learn vcpkg ([Managing dependencies in a C++ project with vcpkg | Declaration of VAR](https://decovar.dev/blog/2022/10/30/cpp-dependencies-with-vcpkg/)). Thanks!
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [February 20, 2026, 2:09pm UTC](https://discourse.cmake.org/t/best-way-to-have-a-library-package-install-a-main-cpp-and-run-add-executable-in-context-of-user-project-when-it-calls-my-cmake-function/11200/4 "2026-02-20T14:09:06Z")
One can also make an `INTERFACE` target with a source file. Then instead of having to construct the path to `memvfs.c`, the user can just link to that target.