[CMake] How to deal with generated source files (w/ dependency tracking) for globs

[Nicholas Braden]

Okay, so I tried my own suggesting and found that it doesn't work at
all (it's more complicated than I thought). However I want to ask you
about your logic here - you say that when the configure step runs, it
cancels XCode's build and so the user has to run the build a second
time. If we use a script to generate a file or just touch one of the
cmake files for every build, that means that every build will be
cancelled and XCode will never move on to actually compile anything.
The only way to actually let a build not be cancelled is either to run
`cmake --build .` from the command line instead of using the IDE, or
to not modify any CMake file, which requires some pretty elaborate
scripting to accomplish. Even just touching the modified date of a
CMake file will cause the configure step to run. At this point I think
you should just tell your users to manually run the configure step
whenever they add or remove a nim source file, because either way it
will be a two-click process. There is no way I see to have the magic
single-click build you want given XCode's limitations. But if you ever
do find a way I'd be interested to hear.

(Though, I don't know how XCode treats External Projects - maybe you
could get it to work that way, but it'd be ugly)

On Wed, Apr 6, 2016 at 6:28 AM, Eric Wing <ewmailing at gmail.com> wrote:
> On 4/4/16, Nicholas Braden <nicholas11braden at gmail.com> wrote:
>> I haven't tested this myself, but instead of using a glob, you could
>> have a build step that generates a CMake script file with the list of
>> generated files in it (e.g. via execute_process to run another CMake
>> script whose only job is to generate the CMake script inception-style)
>> and just include the generated file - CMake will see that the CMake
>> file has been modified during every build but will still handle source
>> file changes correctly. Worth a shot.
>>
>
> Thanks for the reply. So if I understand this correctly, this is what
> the workflow is going to feel like.
>
> - User adds their Nim file to the CMakeLists.txt
> - CMake detects a change and a bootstrap generate/update takes place,
> and my stuff re-runs the Nim compiler.
> - Also during this phase, I need to generate another CMake script
> which contains the list of files the Nim compiler output.
> - Since this other script is also under CMake change tracking, this
> will trigger another CMake change detection and
> bootstrap/generate/update.
> - Now the generated build system has the updated list of generated .c
> files to compile and will finally compile it.
>
> Does this sound right?
>
> My major concern is that the two bootstrap phases kind of break the
> flow. What I mean by that is that in Xcode for example, when a
> bootstrap/generate/update happens, it actually causes your Build/Run
> (run button) action to abort midway through. You sit there expecting
> it to build, but CMake's regeneration was the only thing that
> happened. You must hit the Run button again to actually build/run.
> Kind of annoying and also really confusing for people who don't
> understand this because it isn't obvious why this happened.
>
> But in the above example, there are now two bootstrap phases. So
> assuming this works, I think the user will have to hit the Run button
> at least 3 times before something actually builds/runs. I think this
> is going to feel real broken and feel like dumb luck something
> actually built.
>
> So I was hoping to find a one-step bootstrap solution instead of two-step.
>
> Thanks,
> Eric