Mbld: Open Questions.

[Ori Bernstein <ori@xxxxxxxxxxxxxx>]

And the email I was writing when I opened the old mbld email, and then
fired it off accidentally.

So, I announced mbld a little while ago. In case there are new subscribers,
see below for the announcement.

    http://eigenstate.org/archive/myrddin-dev/Sep-2014/0000003.html

So, now that there's a bit of experience using it, there are a few
questions on what features I want going forward, and how to handle
them.

configure scripts

    With the 'make' based systems, I would ship with a configure script
    that handled things like, eg, figuring out which prefix to install
    programs to, which assembler to use, and so on.

    With mbld, I currently support command line flags for the prefix
    and the destdir, but these are not available to the source code
    in any way, and I'm not sure if they should be, or how.

    I really want to avoid something like autoconf, and library probing
    should be a solvedish issue regardless. Still, I feel like I may end
    up running into some issues here if I don't try something.

    How do we want to handle this? Should we still be relying on system
    probing shell scripts? (ugh)? Is there any better option that we
    should be looking at?

Platform specific code.

    At the moment, my makefiles have a rule that looks like:

        %.myr: %-$PLATFORM.myr
            cp $@-$PLATFORM.myr $@.myr

    Which allows you to have a platform specific myrddin file, and get
    the appropriate one selected. Right now, mbld does a relatively crude
    form of this, in that it will recognize .myr files with a +platform.myr,
    +platform-arch.myr, or +arch.myr suffix, and compile them. At the moment,
    it has no knowledge of specificity, though, so it will get confused if
    you have a foo.myr and a foo+linux.myr. Which one will get built is kind
    of up in the air at the moment.

    How do we want to handle this? Should myrbuild handle this, and know
    about platform filtering, or am I barking up the wrong tree? I've seen
    someone suggest making the Myrddin toolchain just expand environment
    vars in use files, so you  would be able to do "use foo$sys.myr" to
    include the right file. I like the idea, but it has the disadvantage
    of not allowing fallbacks.

    Also, how would this work for assembly fast paths? Since the assembler
    doesn't produce use files, we need to figure out something for the case
    where we have:

        foo.myr
        foo-x86.s
        foo-armv7.s
        ...

    Since if we use 'foo.use', we only get a usefile if we aren't on x86
    or arm.


Utility libraries.

    Right now, utility libraries aren't supported. I'd like to allow you
    to create uninstalled libraries that binaries or other libraries can
    depend on within a package. Any thoughts on how this should be
    implemented?

Packaging integration.

    I want to make it easy to generate distro packages, but clearly
    having code for each of the dozens of distros/platforms that I never
    touch isn't scalable.
    
    I have no idea what we would want to do for packaging integration.

Bootstrapping.

    I have no idea if/how I should be doing the bootstrapping. I'd like
    to use this code for building things like libstd, libbio, libregex,
    and others. But it's written in myrddin, and they're written in
    myrddin. I'm not sure what the best way to fix this is.

-- 
    Ori Bernstein