Do not enforce _d as CMAKE_DEBUG_POSTFIX

[stefanct]

I am not entirely sure (yet) if this was deliberate because there are grave repercussions but I certainly do not want a suffix that complicates my life when linking in my own project... :) So far I had no problem building for amd64 and cross-compiling the runtime part for arm whatsoever. Do I miss something?

[mikkelfj]

Thanks. Well, it seemed like a good idea at the time, and for me personally, it is useful in /lib> or /bin when debugging or testing release. For users, there are warnings that are important to track down bugs when building with extra checks, especially in src/runtime/builder.c, so I imagine others will benefit from easy access to a debug build.

Either way, I cannot just remove the suffix as it would break the workflow of others. But since you have taken care of that in the PR, this could be fine.

I'm just not sure if this is the right way to go about it:

There is also the issue of dumbing the content in the project-root in the first place. Maybe we want a flag for regular build type or developer build (default). I do work with CMake but I'm not an expert in how standard configurations are to be, on different platforms.

[stefanct]

I am also not an expert on CMake at all and I regularly wrestle with its hostility towards embedded projects and cross-compiler setups that are often a complete mess - often because CMake's ideas of what is a good setup are... debatable to say the least :)

The patch does not remove the possibility for the suffix at all and leaves the existing _d in place as you noticed. I totally see the point in that option. It was just a deal-breaker when integrating flatcc in our build environment/CI pipeline. I don't remember the details - I probably could have worked around it - but I got the impression that this should be seen as a bug as it enforces something on the user unnecessarily.

FWIW, I build and install flatcc in a docker container for CI and the integrate it into an existing CMake project with the help of CMake's ExternalProject that allows me to easily specify CMAKE_ARGS, e.g., -DCMAKE_DEBUG_POSTFIX= to get rid of the prefix but also -DCMAKE_C_FLAGS=-mcpu-cortex-m7 ... to cross-compile. I use the resulting RT libs then directly from the build directory for linking my project.

I am fine with any or even no upstream solution. Internally I'll be using this for now since I had to come up with something and therefore it's no pressing issue for me. However, if my change does not break any existing use cases I think it's an improvement no matter what follows.

[mikkelfj]

Thanks for the feedback. I'm a bit concerned with the proliferation of options, so if you don't mind, I'll let this PR sit for while and maybe someone has a suggestion since it is not urgent for you.

BTW: if you only need the rt files, you don't really need FlatCC's build system at all, just add the files to your regular build. You just want to make sure to get the include files.

[stefanct]

All good.

Well, I needed to build flatcc itself too anyway. But I think I have never tried directly including the runtime/*.c files in my build although it's documented. Not sure why. I think I was rather confused by the whole situation of flatc vs flatcc, flatcc's RT libs etc. that I did not recognize that opportunity. :) That should have worked too and it's a nice feature indeed. OTOH it's easier to include in multiple CMake targets as a static lib in my case. I think. Thanks for the clarifications (and all your work).