JyNI icon indicating copy to clipboard operation
JyNI copied to clipboard

Makefile changes

Open CalumFreeman opened this issue 7 years ago • 6 comments

Debug and test modes have been built, and there are now builds and cleans for each of the separate eclipse projects, that way you can configure the builds properly in eclipse.

I've also updated the makefile.clan and makefile.osx but I'm not sure how to deal with the windows build.

CalumFreeman avatar Aug 30 '18 14:08 CalumFreeman

This is to do with issue 30

CalumFreeman avatar Aug 30 '18 14:08 CalumFreeman

Thanks for this work. I added two comments which I am not sure if they are issues. Maybe it's just questions or potential concerns. With these resolved I'll gladly merge this.

Stewori avatar Aug 30 '18 17:08 Stewori

I've also realised that the way It's set up, everything is always in debug mode... The only way to fix that appears to have yet more build targets.

I'll also have to update the wiki to reflect the changes

CalumFreeman avatar Aug 31 '18 15:08 CalumFreeman

I would also comment that these commits should probably all be squashed with a commit message that describes what changed rather than being split between so many commits. Something like:

Added tests, debug mode and partial cleans/debug builds to the makefile (updated clang and osx to match)

CalumFreeman avatar Aug 31 '18 16:08 CalumFreeman

What do you think about my suggestion in https://github.com/Stewori/JyNI/pull/33#discussion_r214400955? That would avoid multiple targets and https://www.gnu.org/software/make/manual/html_node/Multiple-Rules.html leaves me a bit puzzled about whether duplicate target is really the right thing. This might be implementation dependent behavior of make tools. (There is not only gnu make around, also cmake ,certainly even more). Then what do you think about renaming in your PR libJyNI(-Loader) -> _libJyNI(-Loader) debug-libJyNI(-Loader) -> libJyNI(-Loader) That would follow your initial notion that a direct caller of such a target would usually intend a debug build. I found that rather handy. I agree debug-libJyNI(-Loader) is more explicit. I'm undecided. What's your opinion?

Stewori avatar Sep 01 '18 01:09 Stewori

Its probably a good idea to do the libJyNI -> _libJyNI change so that it fits the direct caller wanting a debug build idea.

I tried the

_debug: CFLAGS += -g
debug: _debug all

suggestion, but it didn't seem to work, I think that the _debug: CFLAGS += -g syntax isn't creating a target/recipe type thing, especially since directly calling _debug threw an error saying there was no target.

I think it is a separate thing with unhelpfully similar syntax, basically target: variable=stuff is saying "change this global variable to have a different value(stuff) just for this target" rather than saying variable=stuff is one of the pre-requisites/part of the recipe for target. I haven't found it mentioned in any of the Incompatibilities/extra features/missing features sections, that doesn't mean it will work in other make's but it does suggest it is more standard if it isn't mentioned.

I don't know, but I would be tempted to leave it in (possibly with a warning comment) and not worry until someone runs make and it doesn't work. We could put some checks in that warned you if it was meant to add -g and didn't, but I'm not sure how to do that (I'm not a make wizard).

CalumFreeman avatar Sep 12 '18 11:09 CalumFreeman