-
Notifications
You must be signed in to change notification settings - Fork 47
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
Diffucult to use as submodule for build systems other than make and autotools #6
Comments
Just to make this clear : can you not use libssc's makefile ? CMake does actually create makefiles if I remember well ? |
It's more complicated than that. CMake is interesting because it's really more of a meta-build-system. It can create GNU/BSD-style Makefiles, and that's how I use it. However, it can also be used to create, for example, Visual Studio project files so that people using VS have nice integration. There are also a bunch of other generators, but I chose VS for an example because (1) it's popular and (2) I know their Makefile support is very limited (nmake only supports a small subset of what GNU/BSD make do). There are also other build systems, like waf, scons, tup, shake, bake, etc., that may or may not support integrating Makefile-based sub-projects. Even if it's possible, it's probably more work to figure out how to reliably use the Makefile (even with VS) then it is to just reproduce your logic in CMake. |
OK I get your point : basically too much dependency on Makefile can render the building process difficult on some platforms which don't support it very well. I'll see what I can do to get a "cleaner", more standard compilation process. |
I haven't really looked at the code, but couldn't you just do something like this? /* file_to_use_in_makefile.c */
#define SSC_IN_FILE_TO_USE_IN_MAKEFILE
# define SSC_CHAMELEON_1P
# include "whatever.c"
# undef SSC_CHAMELEON_1P
# define SSC_CHAMELEON_2P
# include "whatever.c"
# undef SSC_CHAMELEON_2P
#undef SSC_IN_FILE_TO_USE_IN_MAKEFILE /* whatever.c */
#ifndef SSC_IN_FILE_TO_USE_IN_MAKEFILE
# error "Don't build whatever.c directly; it will be included by file_to_use_in_makefile.c"
#endif
#if !defined(SSC_CHAMELEON_1P) && !defined(SSC_CHAMELEON_2P)
# error "One of SSC_CHAMELEON_{1P,2P} must be defined."
#endif
/* Existing content goes here */ I would think that would be the least invasive way to make such a change... |
Yes we had roughly the same idea ! It's now fixed in a6970a5 . |
It's currently a pain to use libssc as a submodule with build systems other than simple makefiles since there is magic for building 1p/2p versions of some files. If you want to push people to use the shared library I think this issue can be ignored, but I don't think you do.
FWIW, this is causing problems for squash (which uses CMake), but similar issues should pop up for virtually every build system other than simple makefiles (or autotools). Basically, people will have to re-implement that logic in whatever build system they're using (scons, waf, nmake, etc., as well as IDE-specific stuff like Visual Studio project files, xcode, etc. The CMake documentation lists a subset of the possibilities).
The text was updated successfully, but these errors were encountered: