See mock-up here:
i think we should decrease the scope of this to just adding -l flags to the linker. have the build driver pick up libs[+tags].txt, a newline-delimited list of libraries to passed to the linker with -l. modules that require libc would add a static abort in -libc.ha, and local
.o
s are picked up as inputs in module3
I think it's nice to have a few more things, namely automating codegen or building mixed-source modules with languages other than Hare and assembly, so that most software can be built simply with 'hare build'. Not entirely opposed to making the user lean on make a bit, though.
Also, using an ini file rather than something simple like libs.txt would be good to make sure we have room for future expansion. Also interested in using hare.ini to reconsider the inclusion/exclusion approach away from magic file names with +tags.
Oh, and one more note: the exact -l flags are platform-specific, and vary between Linux distros.
Is it planned to be a requirement for modules to have a hare.ini file present? I like the current simplicity of implicit modules from directory structure.
I would like to avoid hare.ini too
mandatory hare.ini is definitely on the table, it would improve a significant number of things. however, i also like the current simplicity quite a bit, so we'll weigh those two against each other once we're closer to doing this
I think a good proposal from an earlier discussion is that we only have to use hare.ini to disambiguate certain situations, such as a module which has submodules but itself has no Hare sources. If a directory has Hare sources in it we can infer that it's a module; if not but it should still be a module then hare.ini comes in.
I agree with this.