Re: Mbld: Open Questions.

[Ori Bernstein <ori@xxxxxxxxxxxxxx>]

On Sun, 14 Dec 2014 12:58:07 +0100
Daniel Cegiełka <daniel.cegielka@xxxxxxxxx> wrote:

> 2014-12-14 6:06 GMT+01:00 Ori Bernstein <ori@xxxxxxxxxxxxxx>:
>
> > configure scripts

Nothing on this?

> > Platform specific code.
> >
> 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 ??).

Hm. Thinking about this, I'm not sure what to do with ambiguous matches either,
For example: foo+linux.myr, foo+x64.myr.being built on x86 linux.


Presumably I'd want to pick the 'most specific', but I'm not sure how to define
"most specific", especially if the number of matching attributes is the same.
I guess I'd also eventually want negated attributes, like 'foo+!plan9.myr', or
os-class attributes, like 'foo+posix.myr', and I'm not sure how to handle that
either. especially in terms of defining them.

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

Responding to myself: For this, I'm thinking I may just want to write my own
assembler that knows how to do exported Myrddin types:

.func foo : (int, int, char -> int) {
	/* preamble */
	/* body */
	/* postamble */
}

(curly braces may be useful for knowing symbol sizes, allowing us to do some
things like deduplicating generics/strings/... across modules)

As a quick hack, I may just look at handling a .iface file that would
only be used to create a use file when compiling assembly, but I don't
like that so much.

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

Yes, definitely going for static linking. It lets me do a few things like
cross-module inlining. And since I support generics, which get generated
by the module that uses them, some code will always get statically linked
regardless.

I was wondering if there was a sane way of doing somthing like

    mbld -p deb,rpm,...

I don't think there are, though.
 
> >
> > 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.

Yeah, I guess that there's no way around it. I'll probably look at having
some signed "blessed versions" online, which get fetched and used to
bootstrap.