Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TRIBITS_ADD_EXECUTABLE missing ADD_EXECUTABLE properties #76

Open
lefebvre opened this issue Jul 9, 2015 · 3 comments
Open

TRIBITS_ADD_EXECUTABLE missing ADD_EXECUTABLE properties #76

lefebvre opened this issue Jul 9, 2015 · 3 comments

Comments

@lefebvre
Copy link

lefebvre commented Jul 9, 2015

Ross,
The TRIBITS_ADD_EXECUTABLE does not provide a handle for passing thru the executable properties WIN32 and MACOSX_BUNDLE for the CMake ADD_EXECUTABLE function.

@bartlettroscoe
Copy link
Member

Don't remember seeing this Issue before (must have slipped through the cracks).

How do the properties WIN32 and MACOSX_BUNDLE behave in a Linux build? Are they just ignored? How common are these?

In think you can set the property WIN32_EXECUTABLE with using SET_TARGET_PROPERTIES() after calling TRIBITS_ADD_EXECUTABLE() as described here. It looks like you can also set the property MACOSX_BUNDLE using SET_TARGET_PROPERTIES(). Therefore, one can do that as a workaround if nothing else.

So do you think that TriBITS should support these as extra calls to SET_TARGET_PROPERTIES() or should it add more options to TRIBITS_ADD_EXECUTABLE()? I suspect that ADD_EXECUTABLE() supports the properties WIN32 and MACOSX_BUNDLE in order to maintain backward compatibility but that Kitware did not want to keep loading up more properties into ADD_EXECUTABLE() so they supplied those through SET_TARGET_PROPERTIES(). Why did not Kitware add a bunch of other properties directly passing them through ADD_EXECUTABLE()?

I think the design principle is that TriBITS should support the 95% use case with the simple wrappers but make the other 5% of less common or dangerous/confusing use cases possible so as not to restrict the usage of CMake by projects that use TriBITS. However, to maintain consistency and compatibility, we can't let packages use CMake in an arbitrary way. That is the price we pay for interoperability of lots of packages built from source in the same CMake project.

This is similar to #95 for TRIBITS_ADD_LIBRARY(). However, in the case of #95, the STATIC|SHARED options can't be set a properties so they have to be passed through. That is not the case for WIN32 and MACOSX_BUNDLE. They can be set after the fact as properties so we have a choice.

@bartlettroscoe
Copy link
Member

@lefebvre, can you please look at my comment above and see what you think?

@lefebvre
Copy link
Author

I am going to proceed with a merge request on this case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants