drogon_ctl create subdirectory <subdirectory_name>

[ariyo-live]

I have an existing mac os x project that I want to add drogon to. I have some mac specific settings in the CMakeLists.txt file, and I would rather not swiss-army-knife the project. By swiss-army-knife, I mean add too many different functions to the same project. This creates ambiguity and risks in editing and maintaining the code. To resolve this problem, there can be a "drogon_ctl create subdirectory " command that creates a subdirectory with a library based CMakeLists.txt file that works with a parent cmake file that uses the add_subdirectory command. As of now, I tried creating a project and moving it into a subdirectory, but there were link errors. If you can help those of us who say "no" to swiss-army-knife coding, I would appreciate it! 😉✌🏻

[ariyo-live]

BTW: My previous link errors may have been a different problem. Now, when you put drogon in a subdirectory, change add_executable to add_library, and build it from a parent cmake file, it fails to find string_view and starts looking for the boost string view which I don't have installed on this particular system. Maybe, it is not resolving __cplusplus correctly. I hope this helps. ✌🏻

[an-tao]

I can't reproduce the link errors, please make a simple example repo on github that adding drogon project as a subdirectory, I'll figure it out.

[rbugajewski]

@ariyo-live I have one Drogon project that I use across different platforms, macOS included. I took a short look into my CMake file and there are some platform specific configurations, but it’s really just a couple of lines and definitely not on a Swiss-army knife level.

While I understand your basic desire to cleanly split configurations, and maybe even your projects, I fail to understand what the issue is or what you are trying to solve? By looking at my projects, this structure would add overhead, and in the end I would have more code / configurations to maintain. Maybe my projects are too small, and I fail to understand what you’re trying to achieve? Giving us concrete examples instead of a nice looking Swiss-army knife maybe could give us more insights into your issue and try to find a solution 🙂 I do not deploy Drogon to hardware-constrained environments, just servers, desktops, and mobile, so maybe I just miss something here?

Personally I add my Drogon-dependent CMake project as a library to my Xcode projects, and don’t even try to integrate it with code bases with platform-native functionality. This gives also a clean split between what can be developed cross-platform, and what has to be developed for every platform (like the GUI). Maybe this could also work for you?

[ariyo-live]

I can't reproduce the link errors, please make a simple example repo on github that adding drogon project as a subdirectory, I'll figure it out.

Thanks for your help An. I have some other pending work, so in the coming days, I will get up a demo repo to show you.

[ariyo-live]

@ariyo-live I have one Drogon project that I use across different platforms, macOS included. I took a short look into my CMake file and there are some platform specific configurations, but it’s really just a couple of lines and definitely not on a Swiss-army knife level.

While I understand your basic desire to cleanly split configurations, and maybe even your projects, I fail to understand what the issue is or what you are trying to solve? By looking at my projects, this structure would add overhead, and in the end I would have more code / configurations to maintain. Maybe my projects are too small, and I fail to understand what you’re trying to achieve? Giving us concrete examples instead of a nice looking Swiss-army knife maybe could give us more insights into your issue and try to find a solution 🙂 I do not deploy Drogon to hardware-constrained environments, just servers, desktops, and mobile, so maybe I just miss something here?

Personally I add my Drogon-dependent CMake project as a library to my Xcode projects, and don’t even try to integrate it with code bases with platform-native functionality. This gives also a clean split between what can be developed cross-platform, and what has to be developed for every platform (like the GUI). Maybe this could also work for you?

Yeah Rafal, we can add a small number of project components in our builds and code without it going out of control. It can reduce maintenance time from having multiple configurations in the short-run which makes your point that this isn't an issue in what we see in the examples that I have given. Though, as a habit, it becomes a psychological conditioning, and when it comes time to make a project scalable with interchangeable parts, we find multiple components fused together in the same file, making it difficult to move the project forward until that ambiguity is cleared up. In my experience, ambiguity laughs at our hopes of scalability, and clarity is the angel freeing us from her bonds.

[ariyo-live]

Hey @an-tao and @rbugajewski, here is a repo that reproduces the problem. It uses the drogon docker image, adding only mariadb and my basic http_server project skeleton with a simple test handler. You can open it with vscode remote containers or run the test.sh script in the .devcontainer directory. The README explains how to reproduce the problem. No rush... I am working around it for now. Thanks for your help. ✌🏻

https://github.com/ariyo-live/drogon_subdirectory

[an-tao]

cmake.patch.gz @ariyo-live I made a patch to fix your project, please check it.

[ariyo-live]

Thanks for the correction @an-tao, and my apologies for the delay. For the most, part it worked. On your docker container, it's gcc 8.4, so I updated the patch (for anyone else reading this thread) to c++17, rather than c++20 in the prior patch.

cmake.patch.gz