Relative path dependencies

[KholdStare]

Hi Andrzej, it's me again :)

I came upon another use case that I couldn't express, and those were unittests. In a directory that looks like:

.
├── include
├── src
├── Rules.top
└── unittest
    └── Rules.mk

The unittest has to depend on the parent. This is convenient when one wants to place unittests near the location of the actual source code.

This change allows relative paths in _DEPS variables to allow for this.

[aostruszka]

Hello Alex

The way I do it is by defining alias for that "factorial lib" in it's Rules.mk, that is right after defining TARGETS := factorial_lib.a and subdirs I would put: FACTLIB := $(OBJPATH)/factorial_lib.a and then in unittest I would specify deps as: factorial_test$(EXE)_DEPS = $(FACTLIB) factorial_test.o

That should probably work for your test case (I have not tested). As you already mentioned specifying fake path is something a bit bothering me. And using an alias allows for an easy referral to this lib in any part of the project tree.

I'll keep that open for some time and will think it over again.

Regards Andrzej

[KholdStare]

Hi Andrzej,

That makes sense. I would definitely use the alias when combining libraries for the final result, but it may not fit the unittest case, in some situations.

Here are a few observations I've made:

• Unittests usually only care about a very localized set of files. It may be useful to refer to files "nearby" in the hierarchy because of this.
• For example, I might have several unittests that only link against small portions of a library, perhaps a single .o file. In that case i can do ../small_part.o in the _DEPS to express that, instead of linking against a whole library.
• Taking this one step further, perhaps the unittests wants to link against a "stub" of one of the .o files, so one could mix and match unittest stubs with actual implementations. In that case we don't need the whole library too.
• An alternative to doing fake paths is to actually express them fully: $(call real_to_build_dir,$(d)/..)/factorial_lib.a . It doesn't lie, but it's a lot more verbose. Also, the changes required to support that are exactly the same as for the fake path.

I also don't like the "fake" path approach, but it seems a very convenient way to refer to things that are local.