Bug #2454

Dependancy build: relative file paths.

Added by Lakie about 8 years ago.

Status:NewStart date:2011-03-21
Priority:LowDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

I've found a small issue, partly because of the way I've been designing my repository, in particularly to do with relative files paths used in my #include directives.

I have the following folders in sprites/nfo/:
lang/
steam/

For my header.pnfo (included by mygrf.pnfo):
#include "lang/action8.lnfo"

This breaks the mdep.py script, leaving it to put lang/action8.lnfo into the 'mygrf.src.dep' file, breaking the generation of my language nfos.

For my steam/engine.pnfo (included by mygrf.pnfo):
#include "../lang/engine.lnfo"

This just doesn't work with mdep.py at all, it leads to just putting ../lang/engine.lnfo, which obviously breaks any file generation.

I have tried fully qualified names in includes but whilst this fixes the mdep.py entries, it causes gcc to break on pre-processing as it appears gcc expects the include paths to be relative, I imagine there are two ways to fix this, either change gcc to have the repo root as an include directory, or change mdep.py to handle relative paths for files which need to be generated.

I decided to go with the latter for my hack attempts to circumvent the issue, the idea being allowing the check of relative paths before checking all include paths, for files which exist this is simple, where files don't exist I took the assumption that if the folder exists then use the qualified version of the relative path. Its not perfect in any way but does solve my issues.

I've attached two versions of my hack (I use the second version currently).

mdep-idea-1.diff Magnifier (1.69 KB) Lakie, 2011-03-21 16:04

mdep-idea-2.diff Magnifier (1.97 KB) Lakie, 2011-03-21 16:04

Also available in: Atom PDF