Prefer start module option to heuristics #45
Conversation
Useful for defining a start module that doesn't have start/0 (but main/1). Signed-off-by: Paul Guyot <[email protected]>
pguyot
force-pushed
the
w44/start-module-precedence
branch
from
1ad714c to
bb6c95c
Compare
UncleGrumpy
left a comment
UncleGrumpy
left a comment
There was a problem hiding this comment.
Thank you for the test. I feel much better now about future changes not breaking anything. I did catch one other small detail I overlooked during my first review.
| case lists:member({start, 0}, Exports) of | ||
| true -> | ||
| if | ||
| StartModule =:= Module -> |
There was a problem hiding this comment.
I should have thought of this sooner, but should we add a check here that init/1 is exported to make sure it's a valid start module before we set the flag?
There was a problem hiding this comment.
I am a little bit confused about init/1 being exported since we don't have any init/1 function exported indeed (except maybe in gen_server or supervisor callback modules).
The point of this PR is that if user specifies the start module,
we should not use any heuristics and trust them. User in this case would know they have the proper init module in the libs partition.
We should get rid of the libs partition and have proper boot scripts, but this is not this PR.
There was a problem hiding this comment.
Apologies, I meant main/1. That was what I was wondering, do we blindly accept any start module (even if there is no currently supported mechanism for actually starting it), or should we make sure it’s valid and can be started by AtomVM?
I have no strong feeling, but it does seem preferable to at least warn the user (if not abort packing with an error) that the start module can’t be started by the VM, rather than wait until runtime and let the user sort out the runtime error.
2 participants
Useful for defining a start module that doesn't have start/0 (but main/1).