The point of a debug build is to check as much as possible. I am not sure I understand why you want to make a debug build and not run the sanitizers. Why would you not use a release build? I am happy to take the PR if it makes sense, but I do not understand the reasoning. Can you please explain?

Thanks for the feedback, I totally get your point. The only thing is if you "include" libplctag in another project, (using FetchContent / ExternalProject stuff like that) you end up using existing cmake targets (let's say libplctag_static) then if you do a debug build downstream targets need to be built / linked again asan.so too.

This kind of impose to other parts of the project to use sanitizers in debug mode no matter what. For a big code base, this is a big constraint, compile and run time could be massively affected.

Another solution would be to use libplctag in release mode, in a debug build, possible but a little bit ashamed as we could not break in and get proper stack if crash append in the lib.

Ence why I think optional sanitizer (with of course default ON in debug) could be a simple / less invasive way.

Hmm, that makes some sense. What kind of other libraries are you including in the project?

Basically all our own code + a lot of extra third party lib related to other PLC / protocol. Like I said I can also "include" libplctag differently, this is just that cmake fetch_content is somehow practical.

On that note the fact that the linux static lib is renamed (.a lib versus cmake target) make use of fecth_content non straight forward. I think if you want to increate ease-of integration in other based-cmake projects, there is some minimal changes that can enable this. Maybe I can prepare anothre PR to open the discussion.

@vrince I was looking into creating a vcpkg port for libplctag, but I encountered an issue that may be fixed by a PR that makes the CMake files a bit more fetch_content friendly.

Basically all our own code + a lot of extra third party lib related to other PLC / protocol. Like I said I can also "include" libplctag differently, this is just that cmake fetch_content is somehow practical.

On that note the fact that the linux static lib is renamed (.a lib versus cmake target) make use of fecth_content non straight forward. I think if you want to increate ease-of integration in other based-cmake projects, there is some minimal changes that can enable this. Maybe I can prepare anothre PR to open the discussion.

The main issue is that during static builds the dynamic libraries are built anyway, I haven't checked the other way, but I would guess that the static libraries are built during a shared build. Currently I am working around this by removing the shared library files after the build process, but ideally we wouldn't waste the effort of building the unnecessary files in the first place.

Do you think this issue could be fixed in the small PR you were thinking about, or do you think that would that require a more substantial refactoring of the CMake files?

On Linux it's pretty straightforward to have static lib only, it's been a while since I pulled my hair trying to build something on Windows, so maybe you are right simply setting BUILD_SHARED_LIBS to OFF ... Do you want me to take a look ? If you give a little bit more context, I can give it a shot.

@vrince I have done some work on creating a patch which will permit libplctag to integrate with the vcpkg build system. I did have to use a conditional to separate the static and shared builds. You can see my patch for the pending vcpkg port at cmake.patch.

The problem with static and shared library building on windows is that the static library extension .lib is identical to the import library extension .lib. This causes a name collision if both static and dynamic libraries are built and installed to the same directory. In #270 @Joylei opted to change the name of the windows static library to include _static in the filename

set_target_properties(plctag_static PROPERTIES VERSION "${libplctag_VERSION_MAJOR}.${libplctag_VERSION_MINOR}" OUTPUT_NAME "plctag_static")

I have an open issue (#435) to discuss some of the changes I made to make libplctag more friendly for vcpkg.

If you think it will be helpful, I can push my vcpkg branch of libplctag to github.