Although I have a couple of inline comments, I wouldn't object to committing this as-is. Touching up would be fine too.

I took a look at cabal-install and it seem to have a bootstrap script that would allow building it without old bsd.cabal.mk stuff. So, I'll follow second way and try to hack hs-cabal-install and hs-xmonad ports to make them "standalone".

Thank you :)

Can I get some final accept on this, I updated the open issues

In D19500#419336, @imp wrote:

In D19500#419197, @markj wrote:

In D19500#418483, @imp wrote:

Here's what I had come up with for a glibc compatable header. Feel free to steal any or all of this. Foundation copyright is fine.

I didn't bother to fix the namespace pollution when I did this, but I was never targeting MESA. I did this to save me from hacking a dozen places in nvme-cli. The pollution was fine for the nvme-cli.

For now I'm just trying to create a minimal header that survives an exp-run; we can always add to it.

OK. If we're doing an exp run, then maybe we should include my stuff so we can do just one. It was done by examining a number of different versions of endian.h to figure out what Linux users want to the largest extent possible w/o violating POLA...

OK, sounds good. We can try that in the next quarter.

This seems like a good accounting change. Thanks.

I meant additionally, to your patch here -- as ecm would be pulled in at build, and with it linguisttool.

In D19629#420289, @tcberner wrote:

We should look into only build depending on ecm now for the desktop ports.

We should look into only build depending on ecm now for the desktop ports. -- On the other hand, linguisttools is also rather lean in dependencies...

lgtm, and committed.