Re: [PATCH v2] gnu: Add dub-build-system.

[Danny Milosavljevic]

Hi Ludo,

> Do you have experience using it on real DUB packages?  IOW, how complete
> is it?  :-)

Yeah, I've tested it on a small subset of all code.dlang.org packages. About 
half of the ones I tested work fine. This is my log:

OK: (define-public d-taggedalgebraic
OK: (define-public d-memutils
NOT: (define-public d-libasync unittest failure
NOT: (define-public d-eventcore by libasync
OK: (define-public tsv-utils-dlang [bin directory?!]
OK: (define-public d-lapack
OK: (define-public d-cblas
OK: (define-public d-money
NOT: (define-public d-units-d unit tests fail
OK: (define-public d-libevent
NOT anymore: (define-public d-llvm-d
OK: (define-public d-htmld
OK: (define-public d-cssd
OK: (define-public d-openssl
NOT: (define-public d-mail can't find [d-]openssl
NOT: (define-public d-secured can't find [d-]openssl
NOT: (define-public d-botan-math [tests crash]
NOT: (define-public d-botan [dependency on d-botan-math - which will fail]
OK: (define-public d-urld
OK: (define-public isitthere
NOT: (define-public d-imaged ; dependency on undead which is probably bad.
OK: (define-public d-matplotlib-d [huge deps]
NOT: (define-public d-universal ; tests fail
NOT: (define-public d-future ; requires d-universal - which will fail
OK: (define-public d-docopt
NOT: (define-public d-requests ; depends on d-vibe-d - which will fail
OK: (define-public d-concepts
OK: (define-public d-gtk-d ; missing gdata
NOT: (define-public d-pyd ; Python 2 should be UCS-4 but isn't.
NOT: (define-public d-vibe-core ; depends on libasync - which will fail
NOT: (define-public d-vibe-d ; depends on d-libevent 2.0.1 - which it can't 
find for some reason
OK: (define-public d-derelict-util
NOT: (define-public d-derelict-sdl2 ; tries to write into d-derelict-util's 
immutable directory
NOT: (define-public d-derelict-ft ; tries to write into d-derelict-util's 
immutable directory
NOT: (define-public d-bdb2d ; unknown error 6995216
NOT: (define-public unde ; depends on d-bdb2d - which will fail
OK: (define-public d-wave-d
OK: (define-public d-assert-that
OK: (define-public d-compile-time-unittest
NOT: (define-public d-tcenal ; requires d-compile-time-unittest 0.0.3 but can't 
find it for some reason
NOT: (define-public d-libdparse ; requires newer ldc (requires ldc 1.1.0)
NOT: (define-public dfmt ; requires d-libdparse - which will fail.
???: (define-public d-antispam
???: (define-public d-userman
???: (define-public vibenews
OK: (define-public d-syscall-d
OK: (define-public d-quantities

And I've attached the actual package definitions (these are WIP).

>For the final patch, could you add a short description under “Build Systems” 
>in guix.texi?

Sure.

>You can remove keyword parameters that don’t make sense like this one.

Yeah, but maybe I should use them instead. Will investigate :)

>s/Rust/DUB/  :-)

Whoops, thanks :)

>Rather: (chmod "." #o755).

Thanks. Note that it's a workaround because git-download leaves the build 
directory read-only for some reason. Should the problem be found and fixed 
there? Or is it on purpose?

>“vendor”?

Yeah, a Rust term which I reused here. It means a directory with all the 
bundled dependencies (here we symlink the dependencies from our store 
dynamically).

>Could you add a comment above explaining why this needs to be done?

Sure. (it prepares a directory which can be used to find all the (D) 
dependencies by going just one level down; earlier versions just used 
/gnu/store directly but that would mean if you put such a package (without any 
subdirs in it) into your profile it would pollute the root)

I'm just thinking out loud about the comment :)

Something like this?

;; Prepare one new directory with all the required dependencies.
;; It's necessary to do this (instead of just using /gnu/store as the 
directory) because we want to hide the libraries in subdirectories lib/dub/... 
instead of polluting the user's profile root.

>> +  ;(setenv "CC" (string-append (assoc-ref inputs "gcc") "/bin/gcc"))  
>Remove.

Ok.

>If HOME is relied on, please add a comment explaining why.

The dub build system uses it to find or create the .dub directory wherein it 
puts everything it built. I've found the place in DUB where one could patch 
that out: In source/dub/dub.d it says:

        private void init()
        {
                import std.file : tempDir;
                version(Windows) {
                        m_dirs.systemSettings = 
Path(environment.get("ProgramData")) ~ "dub/";
                        m_dirs.userSettings = Path(environment.get("APPDATA")) 
~ "dub/";
                } else version(Posix){
                        m_dirs.systemSettings = Path("/var/lib/dub/");
                        m_dirs.userSettings = Path(environment.get("HOME")) ~ 
".dub/";
                        if (!m_dirs.userSettings.absolute)
                                m_dirs.userSettings = Path(getcwd()) ~ 
m_dirs.userSettings;
                }

                m_dirs.temp = Path(tempDir);

                m_config = new DubConfig(jsonFromFile(m_dirs.systemSettings ~ 
"settings.json", true), m_config);
                m_config = new 
DubConfig(jsonFromFile(Path(thisExePath).parentPath ~ 
"../etc/dub/settings.json", true), m_config);
                m_config = new DubConfig(jsonFromFile(m_dirs.userSettings ~ 
"settings.json", true), m_config);

                determineDefaultCompiler();
        }

Note the "/var/lib/dub/" and environment.get("HOME").

Do we want to? Which?

I feel uneasy using HOME since the packages themselves could misinterpret it as 
the real home directory of the user and install important things there - maybe 
that would cause silent throwaway. Works well enough it practise, though.

> +  (if (or (zero? (system* "grep" "-q" "sourceLibrary" "package.json"))
> +          (zero? (system* "grep" "-q" "sourceLibrary" "dub.sdl")) ; note: 
> format is different!
> +          (zero? (system* "grep" "-q" "sourceLibrary" "dub.json")))

>Would be best to avoid calling out to ‘grep’.  At worst you can do:
>  (define (grep string file)
>    (string-contains (call-with-input-file file get-string-all)
>                     string))

Thanks. I'll use it. Will it break when it can't find the file? That would be 
bad. Usually there's only one of these files available.

(Note that the json files are JSON actually, so we could use json if we wanted. 
For the purpose we are using it for (finding out whether it's a source-only 
library "template" which can't be linked on its own) I think string search is 
much simpler and less brittle. Also, there's a custom yaml-like format (the 
sdl) which would need custom handling anyhow)

dpacks.scm
Description: Text Data