notmuch on w32

notmuch on w32

[Claudio Bley]

Hi.

I wanted to use notmuch on MS Windows and thus have ported the code to
be able to compile with MinGW and MSYS using the GNU autotools on that
platform.

Now, I'm in the process of streamlining the patches.

As a first prerequisite I integrated gnulib as a git submodule and
added the Makefile.am and configure.ac stuff.

Bootstrapping works OK, basically overwriting the existing Makefiles.

So, up to this point, it would be possible to use the old Makefiles as
well as the autotools generated ones (allowing cross compilation and
out-of-source builds) alternatively.

The next step would be ensuring to include config.h as the first
header in every compilation unit. Furthermore, I'd need to replace
compat.h because that's what gnulib is used for.

My question is: would it hurt your feelings if I'd rip off the old
build system completely and substitute it with an autotools build?

Or, are there any complications / problems I do not yet see?

Supporting two build system in parallel definitely is more
work, but it would be possible if feasible in some way.

Thanks for any opinions.

Regards,
Claudio
 
-- 

Re: notmuch on w32

[David Bremner]

Claudio Bley <claudio.bley@googlemail.com> writes:

> I wanted to use notmuch on MS Windows and thus have ported the code to
> be able to compile with MinGW and MSYS using the GNU autotools on that
> platform.

Do you really need autotools, or was it just the easiest path to get
things working on w32?  

> Now, I'm in the process of streamlining the patches.
>
> As a first prerequisite I integrated gnulib as a git submodule and
> added the Makefile.am and configure.ac stuff.

I'm not really in favour of embedding gnulib (or any other library) in
the notmuch source tree, using submodules or otherwise. I understand the
gnulib authors intend it to be embedded, but the idea of staticly
linking to something whose source tree is 87M gives me pause.  

At least on debian gnulib is packaged as a seperate library; I don't
know how usable it is in that configuration.

I wouldn't say that we are minimalist, but we are making an effort to
keep the dependencies as small as possible, so even setting aside the
question of embedding, the cost/benefit ratio of this new proposed
dependency would have to be discussed.

> My question is: would it hurt your feelings if I'd rip off the old
> build system completely and substitute it with an autotools build?

We have so far avoided autotools on purpose.  For a previous discussion
on build systems, see

    http://article.gmane.org/gmane.mail.notmuch.general/700

(and the rest of the thread).

I don't want to sound too discouraging, but my initial impression is
that your approach sounds fairly intrusive for a benefit (w32
compatibility) that is not a huge motivator for me. 

Speaking only for myself,

d

P.S. in case it isn't completely obvious, I'm only discussing what's
suitable for inclusion upstream.

Re: notmuch on w32

[Felipe Contreras]

On Sat, Oct 19, 2013 at 2:54 PM, David Bremner <david@tethera.net> wrote:
> Claudio Bley <claudio.bley@googlemail.com> writes:
>
>> I wanted to use notmuch on MS Windows and thus have ported the code to
>> be able to compile with MinGW and MSYS using the GNU autotools on that
>> platform.
>
> Do you really need autotools, or was it just the easiest path to get
> things working on w32?

No, you don't. I've compiled many things for Windows using MinGW, and
you don't need autotools.

In fact, autotools makes things worst (as usual), by requiring m4,
perl, and bunch of heavy dependencies.

% make CROSS_COMPILE=i486-mingw32-

-- 
Felipe Contreras

Re: notmuch on w32

[Tomi Ollila]

On Sat, Oct 19 2013, Felipe Contreras <felipe.contreras@gmail.com> wrote:

> On Sat, Oct 19, 2013 at 2:54 PM, David Bremner <david@tethera.net> wrote:
>> Claudio Bley <claudio.bley@googlemail.com> writes:
>>
>>> I wanted to use notmuch on MS Windows and thus have ported the code to
>>> be able to compile with MinGW and MSYS using the GNU autotools on that
>>> platform.
>>
>> Do you really need autotools, or was it just the easiest path to get
>> things working on w32?
>
> No, you don't. I've compiled many things for Windows using MinGW, and
> you don't need autotools.

Me too, using the current configure script with MSYS bash should be no
problem (if there is I'm interested to know where). 

I'd suggest you do a system that attaches to the current system with as
small changes as possible (so you get reviewers) and put all windows
specific things to separate script(s) (which is executed *only* when windows
build is detected). The gnulib dependency could be handled so that in 
case (ext/*)gnulib directory does not exist, first
'git clone git://git.savannah.gnu.org/gnulib.git' is done -- and then
a specific commit is checked out from the clone (git reset --hard <hash>)
This way we get an exact working tree from gnulib but only when someone
attempts to do w32 build (if there are some licensing issues (copyright
assignment papers???) we can require user to manually execute the script
which checks out the repository, maybe with magic command line argument)
A draft of a checkout script is at the end of this email.
(If you desire to build required parts using autotools in your custom
script please do so. In any case nobody will take the responsibility
to support the w32 build :D)


Tomi

>
> In fact, autotools makes things worst (as usual), by requiring m4,
> perl, and bunch of heavy dependencies.
>
> % make CROSS_COMPILE=i486-mingw32-
>
> -- 
> Felipe Contreras

--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--

#!/bin/sh

set -eux

# commit 9f15e6702a27649a59263a7ed571805a979d9e70
# Author: Eric Blake <eblake@redhat.com>
# Date:   Fri Oct 18 10:30:42 2013 -0600

commit=9f15e6702a27649a59263a7ed571805a979d9e70

test -d ext || mkdir ext
cd ext
test -d gnulib || git clone git://git.savannah.gnu.org/gnulib.git

cd gnulib
if git reset --hard $commit
then
        :
else
        git fetch origin
        git reset --hard $commit
fi

Re: notmuch on w32

[David Bremner]

Tomi Ollila <tomi.ollila@iki.fi> writes:

> I'd suggest you do a system that attaches to the current system with as
> small changes as possible (so you get reviewers) and put all windows
> specific things to separate script(s) (which is executed *only* when windows
> build is detected). The gnulib dependency could be handled so that in 
> case (ext/*)gnulib directory does not exist, first
> 'git clone git://git.savannah.gnu.org/gnulib.git' is done -- and then
> a specific commit is checked out from the clone (git reset --hard <hash>)

After looking at gnulib a bit yesterday, it seems unlikely that we need
or want all of it.  It might be simpler to just grab the bits of gnulib
we need and throw them in ./compat. gnulib-tool seems to want autoconf,
but you don't have to use gnulib-tool.

d

Re: notmuch on w32

[Claudio Bley]

Hi.

At Sun, 20 Oct 2013 13:05:54 -0300,
David Bremner wrote:
> 
> Tomi Ollila <tomi.ollila@iki.fi> writes:
> 
> > I'd suggest you do a system that attaches to the current system with as
> > small changes as possible (so you get reviewers) and put all windows
> > specific things to separate script(s) (which is executed *only* when windows
> > build is detected). The gnulib dependency could be handled so that in 
> > case (ext/*)gnulib directory does not exist, first
> > 'git clone git://git.savannah.gnu.org/gnulib.git' is done -- and then
> > a specific commit is checked out from the clone (git reset --hard <hash>)
> 
> After looking at gnulib a bit yesterday, it seems unlikely that we need
> or want all of it.

Yes, it's seldom that one needs all of it.

>  It might be simpler to just grab the bits of gnulib
> we need and throw them in ./compat. gnulib-tool seems to want autoconf,
> but you don't have to use gnulib-tool.

Currently, I'm using these modules for w32 compat:

canonicalize
errno
execute
fsync
getdelim
gethostname
getline
mkdir
netdb
progname
readlink
regex
scandir
sigaction
signal-h
strcasestr
strsep
sys_wait
time_r
timegm 
waitpid
xvasprintf

(some of which you already have implemented)

but those modules in turn depend on other gnulib modules, so you'd end
up with:

    alloca-opt
    areadlink-with-size
    at-internal
    bitrotate
    btowc
  canonicalize
    chdir
    chdir-long
    cloexec
    close
    closedir
    configmake
    d-ino
    dirent
    dirfd
    dirname
    dirname-lgpl
    dosname
    double-slash-root
    dup
    dup2
    environ
  errno
    error
  execute
    exitfail
    extensions
    extern-inline
    fatal-signal
    fchdir
    fcntl
    fcntl-h
    fd-hook
    fdopendir
    file-set
    filename
    filenamecat-lgpl
    float
    fstat
    fstatat
  fsync
    getcwd
    getcwd-lgpl
  getdelim
    getdtablesize
  gethostname
  getline
    gettext-h
    hash
    hash-pjw
    hash-triple
    havelib
    include_next
    intprops
    langinfo
    largefile
    localcharset
    locale
    localeconv
    lock
    lstat
    malloc-gnu
    malloc-posix
    mbrtowc
    mbsinit
    mbtowc
    memchr
    mempcpy
    memrchr
  mkdir
    mktime
    mktime-internal
    msvc-inval
    msvc-nothrow
    multiarch
  netdb
    nl_langinfo
    nocrash
    open
    openat
    openat-die
    openat-h
    opendir
    pathmax
    posix_spawn-internal
    posix_spawn_file_actions_addopen
    posix_spawn_file_actions_destroy
    posix_spawn_file_actions_init
    posix_spawnattr_destroy
    posix_spawnattr_init
    posix_spawnattr_setflags
    posix_spawnattr_setsigmask
    posix_spawnp
  progname
    raise
    rawmemchr
    readdir
  readlink
    realloc-posix
  regex
    rewinddir
    same
    same-inode
    save-cwd
  scandir
    sched
  sigaction
  signal-h
    sigprocmask
    size_max
    snippet/_Noreturn
    snippet/arg-nonnull
    snippet/c++defs
    snippet/warn-on-use
    socketlib
    sockets
    socklen
    spawn
    ssize_t
    stat
    stdalign
    stdarg
    stdbool
    stddef
    stdint
    stdio
    stdlib
    strcase
  strcasestr
    strcasestr-simple
    strchrnul
    strdup-posix
    streq
    strerror
    strerror-override
    string
    strings
    strndup
    strnlen
  strsep
    sys_socket
    sys_stat
    sys_types
    sys_uio
  sys_wait
    threadlib
    time
  time_r
  timegm
    unistd
    unistd-safer
    vasnprintf
    vasprintf
    verify
    wait-process
  waitpid
    wchar
    wcrtomb
    wctype-h
    xalloc
    xalloc-die
    xalloc-oversized
    xgetcwd
    xsize
    xstrndup
  xvasprintf

Of course, you'd also need the configure checks to enable/disable
compiling those modules. Doing this without gnulib-tool / autotools
seems to be a lot of (gratuitous) work.

I don't think that I'll have to time to do this, so I'll just keep my
patches in a private branch then, which saves me the effort of
polishing the patches.

Thanks for your attention.

Claudio