Diffucult to use as submodule for build systems other than make and autotools

[nemequ]

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).

[g1mv]

Just to make this clear : can you not use libssc's makefile ? CMake does actually create makefiles if I remember well ? In XCode you can use an external makefile to build your project so it's not a problem really. But I do agree that for simplicity one .o file should correspond to one .c file, I'll have a look into that and see if I can avoid code duplication by some other means.

[nemequ]

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.

[g1mv]

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.

[nemequ]

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...

[g1mv]

Yes we had roughly the same idea ! It's now fixed in a6970a5c7bbc353a3baf38debb9479802b9dce3e . Maybe I should rename the two .c files that are includes-only (kernel_chameleon_encode.c and kernel_chameleon_decode.c) to some other suffix so they don't get compiled at all ? Not sure about this one. On OSX clang is not clever enough to avoid creating a .o even if the c source is empty. Anyways now every .c is compiled into one and only one .o !