Complete the README

[MartyLake]

It should contain at least the following sections:

• What's the problem this project is trying to solve (the final objective)
• Project description : how this project solves the problem
• Installation procedure / tutorial
• How to contribute to the project

Long texts can be proxied to the wiki.

[chikashimiyama]

Hello, I just began to use FRUT. Apologize if this is a wrong place to ask.
I would like to read more about the goal of the project in Readme. What kind of situation you are envisioning.
What I imagined first was to remove producer and .jucer files completely from the workflow and just use .cpp and .h files of juce project but it was probably my misunderstanding, as far as I read the generated CmakeList file (it still refers .jucer file)

So if I want to add one more file to the project, should I add it to .jucer file, using projucer or edit CmakeList.txt directly?

[McMartin]

Hi @chikashimiyama,

Thanks for using FRUT!

I would like to read more about the goal of the project in Readme.

This is definitely missing from the README file, and I apologize for that. Writing more documentation for FRUT is on my TODO list.

So if I want to add one more file to the project, should I add it to .jucer file, using projucer or edit CmakeList.txt directly?

The choice is yours. You can keep the .jucer file as the main project file, and use Jucer2Reprojucer to convert it into a CMakeLists.txt file on-demand. But you can also decide to eliminate the .jucer file and use only the CMakeLists.txt file.

In the CMakeLists.txt file generated by Jucer2Reprojucer, the original .jucer file is passed to jucer_project_begin as PROJECT_FILE, so the other jucer_* commands can use it as the base for relative paths. For instance, if you have

 jucer_project_module(
   juce_core
   PATH "../JUCE/modules"
 )

then Reprojucer.cmake will join the absolute path to the folder that contains the .jucer file with ../JUCE/modules to form the absolute path to the folder that contains the juce_core module.

However, passing PROJECT_FILE to jucer_project_begin is not required to make absolute paths (since a25d81a). If you don't pass it, jucer_project_begin will use CMAKE_CURRENT_SOURCE_DIR instead. This means that relative paths given to jucer_project_settings, jucer_project_files, jucer_project_module, jucer_export_target, and jucer_export_target_configuration will be made absolute based on the location of the CMakeLists.txt file instead of the location of the .jucer file.

I hope this will help you continue your journey with JUCE and CMake.

[chikashimiyama]

hi, thank you for your detailed answer. now the purpose of keeping that .jucer file is clear.

[McMartin]

I forgot to mention that Jucer2Reprojucer itself is an example of a JUCE-based project that uses Reprojucer.cmake in its CMakeLists.txt file, but doesn't have (and never had) a .jucer file. See Jucer2Reprojucer/CMakeLists.txt:

FRUT/Jucer2Reprojucer/CMakeLists.txt

Lines 59 to 64 in 72adc75

	jucer_project_begin()
	jucer_project_settings(
	PROJECT_NAME "Jucer2Reprojucer"
	PROJECT_VERSION "1.0.0"
	PROJECT_TYPE "Console Application"

[chikashimiyama]

Thank you for your detailed answer!

The reason why I like (modern) CMake is that I can write dependencies between modules in a higher abstraction level, using target_link_library etc. without touching any linker flags and header path etc.
If I make a juce-dependent static library, using reprojucer, and use that static library in a audio plugin project, what's the best practice for associating these two projects? Would it be possible to do that without touching linker flags and header files?

Apologies, I'm also new to Cmake and it might be a stupid question but my goal is not only to use the powerful generators of Cmake but also to maintain the structure of my relatively large project that consists of several juce-dependent static libraries in a more abstract way. so to me it would be tremendously helpful if somebody could write a guide or a tutorial for this kind of situation.

[McMartin]

Reprojucer.cmake is really meant to reproduce what Projucer does. It is not meant to handle complex cases like yours by default, but it might still be possible. I don't think this kind of advanced usage belongs to the README file though, so we shouldn't be discussing that on this issue. Please create a new issue where you describe the libraries and binaries that you want to build in more details, and we can think together about some solutions.