Re: Mbld: Open Questions.

[Daniel Cegiełka <daniel.cegielka@xxxxxxxxx>]

2014-12-14 6:06 GMT+01:00 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.

There is another problem, which is not affected here. What with the
optimization of the specific cpu's instructions (SSE2, AVX, AVX2).
It's important for eg. crypto code (+arch-sse2.myr, +arch-avx.myr,
+arch-avx2.myr ??).

>     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.

It's tiresome topic:

http://harmful.cat-v.org/software/dynamic-linking/versioned-symbols

Wherever possible, I use static linking, and it gives a good
portability. Distro packages is not a problem if we use static
linking.

>
> 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.

If you plan toolchain self hosting (myr only code), then we need
precompiled packages.

Daniel

> --
>     Ori Bernstein
>