On 27 Jul 2013, at 09:34, Riccardo Mottola <[email protected]> wrote:
> The only thing which I don't like about that version is that the different > files are "included" in a class implementation file (.m) and not explicitly > in the makefile. I essentially tried to do the same thing, but with explicit > separation of headers and of course it didn't work. There are two alternatives: - Give the included .m files a .h extension. They're included so this makes sense, although they're not just interfaces, but as long as they're not public headers it's fine. - Unconditionally compile them, but bracket each one in #ifdef __linux__ or whatever. Then you can compile all of them, but you'll likely get a linker warning about empty .o files. > If such a project had to be managed in ProjectCenter it wouldn't work, for > example: project files are added automatically to the make file. I checked > and "make dist" works, but it still might pose problems when distribution > make package lists. There are many good reasons not to use ProjectCenter, and this is one... > I still have stuff to improve, but for now I like the first clean-up, it made > the code (and also the necessary imports) much much better. The only dirty > part is actually my linux code which has tons of ivars. If you use class extensions, rather than categories, then you can also declare ivars in the @implementation context. This will only work with the non-fragile ABI, however. David _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
