YBD gets confused if not run from definitions base directory

[leeming]

Target seems to be calculated with the following
target = os.path.join(config['defdir'], config['target'])
However, if 'defdir' is not set in a config file, CWD is used instead.

This causes issues if trying to run ybd like the following
python ybd.py ../../baserock/definitions/systems/minimal-system-x86_64-generic.morph x86_64

[devcurmudgeon]

this is harder to address than I thought. how far up that tree should YBD start looking for definitions? presumably you don't want it scanning everything from ../../ ? I could hard-code to look for 'definitions' as the directory name, but that's a really ugly hack.

[leeming]

If the directory 'definitions' HAS to exist, and assumes to be at the base, then something like the following might work:

#Fetch path of base morph file to use
arg_basedef=sys.argv[1]
#Split path and find where 'definitions' is
psplit=arg_basedef.split("/")
ix=psplit.index("definitions")

#Gets relative base directory to definitions and path for morph relative to definitions directory
rel_path_def_dir=asplit[:ix]
rel_path_morph=asplit[ix:] 

Or did I not understand the issue? I originally assumed that YBD would pick up the definitions path from the argument passed anyway.

[devcurmudgeon]

currently we have to walk the definitions path looking for all morph files. user can specify strata/build-essential/stage1-binutils.morph, or just stage1-binutils.morph. currently the behaviour (from https://github.com/devcurmudgeon/ybd/blob/master/ybd/__main__.py#L45) is

• if there's a VERSION file here, assume we're in the definitions directory already (but this fails if there's no VERSION, which can be true for early definitions repos since before we introduced versioning) and also fails if we're somewhere else that happens to have a VERSION file.
• if not, look for a directory called definitions below or alongside cwd.

i guess noticing the definitions dir in the passed argument (in your example ../../baserock/definitions/systems/minimal-system-x86_64-generic.morph) would be no worse than the above, but this is clearly a mess...