Diffucult to use as submodule for build systems other than make and autotools about density HOT 5 CLOSED

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.

from density.

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.

from density.

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.

from density.

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

from density.

Yes we had roughly the same idea ! It's now fixed in a6970a5 .
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 !

from density.