I forgot to mention this seems to happen when specified in both weston.ini, and on the command line

What is your test case exactly? How do you specify it?

Note, that desktop-shell.so is a shell module, which must be loaded by --shell option or [core] 'shell' key in weston.ini. Trying to load it via modules is a user mistake.

Is there any case where one cannot easily avoid loading the same module twice?

Should we make "module already loaded" look more like an error?

I was accidentally specifying desktop-shell in --modules with my scripts... I guess it could appear to be more of an error, but I dont think loading a duplicate module that previously only got ignored is worthy of causing Weston to exit.

I'd like to vote for this bug to be closed.

The --modules option is documented, in its man, to be used only for testing. A developer using the --modules option would know to simply re-run weston without specifying the particular module.

End-users incorrectly passing an 'invalid' module as a --modules option would be advised to observe what is documented in man.

The original context of this bug is due to incorrectly specifying a --shell module as a --modules option.

Otherwise, to honor this use case, we'd have to implement additional logic in compositor.c that:

1) Checks the module to be sure it is a valid option for --modules, and if it isn't, prints a helpful message before quitting.
2) Ignores the loading of the valid, specified --modules module and continues, rather  than causing weston_load_module to return NULL and quitting.

We could also make Weston discriminate between module types (backend, shell, generic) by having a type-specific symbol name instead of just "module_init", which would help weston quit with a better error message. I still think quitting is the right thing to do.

Closing.

If you want better errors, that would be a new report. Preferably a new Task in Phab.fd.o.