Addition of source code checks to a CMake script about curl

[bagder]

Thanks, but that's not needed anymore since the --enable-debug switch to configure now used (since e424a1b) will imply running make checksrc.

[elfring]

How does the mentioned script "configure" cooperate with your CMake build specification?

[bagder]

Not at all. configure the script generated by autoconf and is the primary build environment used by me. cmake is a separate build environment that we maintain and provide for those who prefer to build libcurl that way. Two different ways to build the project.

[elfring]

I know that two build approaches are provided.

I hope that the CMake script can a bit improved by this feature request, can't it?

[bagder]

Ah sorry, I didn't understand what it was a question like that. My apologies.

Yes, I think all changes that bring the cmake build more in parity with the autotools build are good and welcome.

[bagder]

So I guess this then concludes this issue since the question was answered?

[elfring]

Do you need another pull request for the small addition of the suggested CMake command?

[snikulov]

Yes. Could you please provide pull request? Just mention that it targeted to fix #160.

[elfring]

The scripts "Makefile.inc" set some variables which are referenced by the check commands.
Would you like to share the corresponding file name lists with the CMake build approach?

[bagder]

@elfring you keep asking weird questions.

No, I don't particular "like to share" that list. But if you want to provide a feature or fix a problem and you can achieve that by sharing that list, then it could certainly be a viable option. Do you?

[elfring]

The file name lists that will be passed to the check commands need to be defined somehow.
I imagine that it will be nice if a single listing would be sufficient for both build approaches, wouldn't it?

[bagder]

So there, that sounds like an excellent use of that list, yes...

[elfring]

I see that there is a software development challenge for the selection of a data format with which both build approaches can also work directly so that data duplication will be avoided.
Further ideas?

[bagder]

Are you saying that the Makefile.inc format is not good enough for cmake?

[bagder]

transform_makefile_inc() is already an existing cmake function provided in lib/CMakeLists.txt that transforms Makefile.inc into something suitable

[elfring]

How do you think about to move the calls of your function "TRANSFORM_MAKEFILE_INC" into the main "CMakeLists.txt" so that corresponding file contents will already be reusable at the top level?

[bagder]

Another strange question. Why would I think about that? If you can provide us with a good reason why we want to move that function then we can discuss it, if you can't then I think it is good where it is.

A proper patch to make a checksrc target for cmake might possibly want that.

But let me ask you again: can't cmake use the {src,lib}/Makefile.inc files as they are already? They use a very generic format.

[elfring]

The automake target "checksrc" calls commands which refer to variables from the areas "lib" and "src", doesn't it?

Do you eventually want to make this target only usable in each subdirectory?

[bagder]

checksrc is a make target, yes. Usable for those who don't build curl debug-enabled because then checksrc is run automatically on the normal make target (at least when configure-based)

I didn't say anything about this being "only usable in each subdirectory".

[elfring]

I guess that the target "checksrc" should work for the areas "lib" and "src" at the top level. I find that corresponding data conversion will be needed in the main "CMakeLists.txt" already so that relevant variables will be appropriately defined there.