[darcs-devel] [patch1908] WIP: drop custom Setup.hs

[Ben Franksen]

Ben Franksen <ben.franksen at online.de> added the comment:

>> We also cannot currently use darcs as a development sub-package without
>> ad-hoc changes to Setup.hs which complicates development of darcsden
>> (and other tools that depend on darcs-lib). This is due to the man page
>> generation which is currently done for the whole package instead of just
>> for darcs-exe. Unfortunately the cabal API so horribly complex that I
>> wasn't able to get this fixed and gave up.
> 
> I haven't worked on darcsden for a while, but I've always used it
> against darcs without any changes to Setup.hs that I remember. Is this a
> recent problem?

I meant using darcs as a "local package" as described here:

https://cabal.readthedocs.io/en/latest/nix-local-build.html#specifying-the-local-packages

This has never worked without disabling the custom build of the man page.

>>> We've simplified a few bits piecemeal over the years but maybe it's time
>>> just take one big leap and drop it entirely.
>>
>> A bold move. It might be a good idea to talk to package maintainers for
>> Linux distros and ask them which parts they actually use.
> 
> Aren't they just going to be running it and packaging the output? Apart
> from the manpage, the changes we would make would be only relevant to us
> as developers.

I have no idea what features they use. Asking doesn't hurt, does it?

>>> [re darcs --exact-version]
> 
>> "One workaround is to write a small script that will generate a `.hs`
>> module with the revision info and then call `sdist`, and then use this
>> script instead of `sdist` for creating tarballs."
>>
>> If that's the way to go, then we don't need a custom Setup.hs to do that.
> 
> I don't think we should care about --exact-version at all with sdist. We
> run sdist when we are making a release, and our releases are tagged, so
> we can trivially identify the repository state from the version number
> if we didn't screw up the release process.

Okay, that makes sense.

> The question for me is whether we care about it the rest of the time.
> Personally I don't, at least not enough to pay the price of a custom
> Setup.hs.

I think we as developers know how to identify the version we run
manually. So yes, this is perhaps no longer needed.

>>>  - Sort out endianness detection (maybe could use the 'cpu' package),
>>>    but performance could be a concern.
>>
>> I must look up why we need that at all. We shouldn't.
> 
> It's in Darcs.Util.Index. Not sure of the details.

Aargh, the index rears its ugly head. The details are pretty much that
we use mmapByteString on the file to read and edit it and that it stores
integers in binary form. This needs to aware of endianness.

>>>  - Look through the other defines in Setup.hs (MAPI?? Do we care??)
>>
>> If we want darcs to work seamlessly on Windows, we should probably care.
> 
> I use Windows and I've never used MAPI, at least not knowingly.
> 
> It would be quite nice to be able to send patches directly from Windows
> though, so perhaps I should care more :-) At the moment I push them to a
> Linux machine and send from there.

That is horrible. I can't believe there is no MAPI library on hackage
that we could use.

> But my long-term view is that we
> should be sending things over HTTP to darcsden rather than investing
> lots of effort in the email interface.

Absolutely. And I wasn't proposing to invest lots of effort, just take a
look, see what libraries are there and use one if we find it suitable.

>> No idea why this needs support form Setup.hs, though. It should just be
>> a build-depends, conditional on Windows, perhaps supported by separating
>> out the "send an email" functionality to an extra module. I will take a
>> look.
> 
> Agreed we should be able to move that kind of logic into the cabal file
> if we need it at all. I'd have to do more research to know whether MAPI
> is actually worthwhile at all though.

Yup. Will look, too.

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/patch1908>
__________________________________