How to shorten OBJPATH when doing out-of-tree builds

[FreddieChopin]

When you redefine OBJPATH to be an absolute path to the build folder like this: OBJPATH = $(TOP)/build/$(d)/$(OBJDIR) The hierarchy of folders "inside" gets really long, because $(d) is an absolute path. It is possible to make it a bit shorter in case you don't need absolute paths (no "external" dependencies) by just dropping $(TOP) from the beginning of $(d) like this: OBJPATH = $(TOP)/build/$(subst $(TOP),,$(d))/$(OBJDIR) But in this approach (out-of-tree build) the OBJDIR part is actually useless. Dropping it from the OBJPATH above or re-defininig it to be empty does not work:

Rules generated ...
make: *** No rule to make target `/c/Users/freddie/Documents/1/stm32_blink_led/b
uild///.fake_file', needed by `/c/Users/freddie/Documents/1/stm32_blink_led/buil
d///main.o'.  Stop.

Would that be possible? I think that out-of-tree build is a more general and universal approach, so it would be a nice improvement. Maybe that is already changed in the new branch - I've seen some changes regarding .fake_file there?

[FreddieChopin]

And there's a problem that in case of out-of-tree builds the clean does not work... If I have OBJPATH defined as above, any variation of "clean" tries to delete files in "/obj/debug/", even though it should use "/build/obj/debug/" - which is the directory in which the outputs really are.

[aostruszka]

Freddie

First of all I have merged eval_hdr with master. No one complained about it so I consider it to be ready for "production", so you can fast fwd your master :) Having said that please take a look at 5b7b478a180896aa99f71d337102a5cd117c8809. It improves previous solution with your suggestion (no replication of $(TOP) under $(TOP_BUILD_DIR)). Additionally there are some minor improvements/corrections related with out of project tree build.

Let me know if this solves your issue? Regards Andrzej

[FreddieChopin]

OK, the hierachy inside top build dir is shorter, but there are still some problems (at least on Windows).

I now have sth like this in my Rules.top:

TOP_BUILD_DIR = blahblahblah

And surprisingly the outputs are in $(TOP)/obj/debug... Whatever I specify there (valid, invalid, absolute or relative) the actual output folder does not change. The clean works, because it searches in the obj/debug, not in the folder specified.

BTW - how would an external dependency be handled? For example a source with an absolute path or something "above" the main folder of project?

[aostruszka]

Freddie

TOP_BUILD_DIR should be absolute path. I'm afraid that I cannot reproduce the problem - I'm working now on Linux (actually Windows is only supported in cygwin environment - but right now I don't have that either). Could you create some minimal example and send me output of "make -p"?

Regards Andrzej

[FreddieChopin]

Here is the output

http://pastebin.com/QKuZ8Qhy

I just took "ex1" from the tree, modified it a bit to work in Windows (no symbolic links, so I copied "mk" folder, Makefile file and renamed Rules.mk to Rules.top in top folder of example). Then I just added following line to Rules.top

TOP_BUILD_DIR := $(TOP)/top_build_dir

The output goes to "normal" folders, just as if TOP_BUILD_DIR was not given at all.

[aostruszka]

Freddie, I've missed important detail of your previous message. I blindly assumed that you'll be modifying TOP_BUILD_DIR defined (actually commented out) in skel.mk just before OBJPATH is being defined. Your definition in Rules.top is much too late since it has to be defined before OBJPATH is being defined. So what you actually get is that at the line 154 in skel.mk there is no TOP_BUILD_DIR and thus OBJPATH is set to $(d)/$(OBJDIR) as shown in your paste at line 627. So if you don't want to modify skel.mk you could try defining it in make invocation like "make TOP_BUILD_DIR:=$(pwd)/build_dir" or you could set it in environment variables. Or simply define it at the end of config.mk - after all these config files are meant for adaptation by the user.

As I've said in other issue - I'll try to clean up things and separate parts meant for user modifications from parts that "ordinary" user should not be touching.