Module loader gets confused easily

[SamuraiCrow]

If the emodules: assign is listed first in the ecx-morphos-dir environment variable and contains a code-bearing emodule from E-VO, ECX/EEC won't load it and won't look for a MorphOS version. If I compile a MorphOS version and put it in ECXMODULES:morphos/ it still doesn't find it if it's inside another directory (even if the module directive specifies the directory). If I reduce the path in the environment variable to just the one it's in it still can't load it. Viewmodule shows the module file is properly formed and perfectly notes the referenced base class module in a sibling directory. This is not working.

[SamuraiCrow]

Update: some confusion could have been solved if I emptied the module cache between uses. I think the issue here is something case-sensitive in the directory name.

[Hypexed]

An early issue I noticed, if it could be called that, is that ECX relied on some AmigaE modules. Or they were acceptable as the main assign, since it's been years I set ECX up. My setup had the EModules assigned to the 68K AmigaE modules with ECX added after that.

A secondary issue could be needing assigns and in this case multi assigns. I've thought for years assigns just complicate it for the user. But this is really because assigns (and application scripts) were never modularised like other components since OS2 when resources like DOS mounts were split and organised into files. I expected app scripts to be added to AmigaOS and especially OS4, as well as assign files, where scripts and assigns would be managed easily as files and an entire assign map would be as easy as dropping files in place. But for some reason this obvious feature to me wasn't thought about for the last 20 years of OS4 development even. Well that's off topic really. :-?

[SamuraiCrow]

@Hypexed
Replied at https://github.com/orgs/EEC-Developers/discussions/4