Can't compile notmuch-delivery

Can't compile notmuch-delivery

[Jostein Gogstad]

Hi,

I'm trying to compile notmuch-deliver, but after I get this error:

  CC     main.o
  main.c: In function ‘main’:
  main.c:432: error: too few arguments to function ‘notmuch_database_open’
  make[2]: *** [main.o] Error 1

Any ideas? Tried with the version that ships with 0.13, and the version in HEAD
(they seem similar though).

I used no arguments to invoke autogen, configure or make.

-- 
Jostein

Re: Can't compile notmuch-delivery

[Tomi Ollila]

On Fri, Jun 01 2012, Jostein Gogstad <jostein.gogstad@gmail.com> wrote:

> Hi,
>
> I'm trying to compile notmuch-deliver, but after I get this error:
>
>   CC     main.o
>   main.c: In function ‘main’:
>   main.c:432: error: too few arguments to function ‘notmuch_database_open’
>   make[2]: *** [main.o] Error 1
>
> Any ideas? Tried with the version that ships with 0.13, and the version
> in HEAD (they seem similar though).

Yes, commit 5fddc07d (*) changes notmuch_database_open() interface. Austin
or Ali may fix that some day...

.. or Someone Else(TM)... patches welcome :D

> I used no arguments to invoke autogen, configure or make.
>
> -- 
> Jostein

Tomi

(*) grep '^[a-z].*otmuch_database_open' * */*
    git blame lib/database.cc
    git log 5fddc07d

Re: Can't compile notmuch-delivery

[Felipe Contreras]

On Fri, Jun 1, 2012 at 8:44 AM, Tomi Ollila <tomi.ollila@iki.fi> wrote:
> On Fri, Jun 01 2012, Jostein Gogstad <jostein.gogstad@gmail.com> wrote:

>> I'm trying to compile notmuch-deliver, but after I get this error:
>>
>>   CC     main.o
>>   main.c: In function ‘main’:
>>   main.c:432: error: too few arguments to function ‘notmuch_database_open’
>>   make[2]: *** [main.o] Error 1
>>
>> Any ideas? Tried with the version that ships with 0.13, and the version
>> in HEAD (they seem similar though).
>
> Yes, commit 5fddc07d (*) changes notmuch_database_open() interface. Austin
> or Ali may fix that some day...
>
> .. or Someone Else(TM)... patches welcome :D

I'd say the one who breaks the API does the necessary changes in all
notmuch code, otherwise what's the point of having the code in the
same repo? This is how the Linux kernel does it.

I would be in favor of reverting these changes, and possibly put them
in a separate branch, until they are ready (as in all notmuch code
compiles).

Cheers.

-- 
Felipe Contreras

Re: Can't compile notmuch-delivery

[David Bremner]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> I would be in favor of reverting these changes, and possibly put them
> in a separate branch, until they are ready (as in all notmuch code
> compiles).

We have already released the this code and put people through the SONAME
bump, so I don't really think reverting the code makes sense. 

I guess we should clarify what it means to accept some code into
contrib. Do we accept to maintain it even after the original contributor
loses interest? 

d

Re: Can't compile notmuch-delivery

[Jameson Graef Rollins]

[-- Attachment #1: Type: text/plain, Size: 485 bytes --]

On Fri, Jun 01 2012, David Bremner <david@tethera.net> wrote:
> I guess we should clarify what it means to accept some code into
> contrib. Do we accept to maintain it even after the original contributor
> loses interest? 

I don't know, but this is one of the reasons I'm against having
"contrib" stuff in the notmuch repo.  If it's not part of the stuff
we're willing to release in source tarballs or binary packages then it
should probably be in a separate repo.

jamie.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Can't compile notmuch-delivery

[David Bremner]

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

Jameson Graef Rollins <jrollins@finestructure.net> writes:

> I don't know, but this is one of the reasons I'm against having
> "contrib" stuff in the notmuch repo.  If it's not part of the stuff
> we're willing to release in source tarballs or binary packages then it
> should probably be in a separate repo.

Just to be clear, ./contrib currently is in the source tarballs, and at
least notmuch-mutt is included in a binary package for debian.

I don't disagree that status is kindof odd, but I don't see the stuff in
contrib as being that different in practice from the bindings. In both
cases we have had incidences of bitrot. The python bindings are
currently not a problem, but both the ruby and go bindings stopped
working at all recently.

Ideally everything would be automated testable, but this is not the case
right now. Somebody (Jani?) mentioned on irc that having things
integrated into the toplevel build system (presumably as an optional
target) would be a start.

I guess we could have some protocol where a "subsystem maintainer" has
to sign off before the release, or we just don't export it to the
release tarball. But then, it would slow the release process down,
especially for point (bugfix) release.

d

[-- Attachment #2: Type: application/pgp-signature, Size: 315 bytes --]

Re: Can't compile notmuch-delivery

[Jameson Graef Rollins]

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

On Fri, Jun 01 2012, David Bremner <david@tethera.net> wrote:
> Ideally everything would be automated testable, but this is not the case
> right now. Somebody (Jani?) mentioned on irc that having things
> integrated into the toplevel build system (presumably as an optional
> target) would be a start.

I think the zeroth-order thing we have to do then is to have the build
include the bindings as well.  Then everyone will be able to see
immediately if the bindings are broken.  I wouldn't even make it an
option, or make it an option to exclude building the bindings rather
than to include.

jamie.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Can't compile notmuch-delivery

[David Bremner]

Jameson Graef Rollins <jrollins@finestructure.net> writes:

> I think the zeroth-order thing we have to do then is to have the build
> include the bindings as well.  Then everyone will be able to see
> immediately if the bindings are broken.  I wouldn't even make it an
> option, or make it an option to exclude building the bindings rather
> than to include.

OK, I can agree with this. Can we get some help from the bindings
maintainers (or other interested people) in getting this working? 
Probably configure should detect/decide what bindings to build.

d

Re: Can't compile notmuch-delivery

[Justus Winter]

Quoting David Bremner (2012-06-01 20:46:59)
> Jameson Graef Rollins <jrollins@finestructure.net> writes:
> 
> > I think the zeroth-order thing we have to do then is to have the build
> > include the bindings as well.  Then everyone will be able to see
> > immediately if the bindings are broken.  I wouldn't even make it an
> > option, or make it an option to exclude building the bindings rather
> > than to include.
> 
> OK, I can agree with this. Can we get some help from the bindings
> maintainers (or other interested people) in getting this working?
> Probably configure should detect/decide what bindings to build.

I like the idea. The thing with the python bindings is that building
them wont detect any errors, one has to import the module. Quick and
dirty python oneliner that doesn't even require installing the
bindings:

teythoon@thinkbox ~/repos/notmuch (git)-[master] % ( export LD_LIBRARY_PATH="$(pwd)/lib" ; cd bindings/python && python -c "import notmuch" )
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "notmuch/__init__.py", line 54, in <module>
    from .database import Database
  File "notmuch/database.py", line 46, in <module>
    class Database(object):
  File "notmuch/database.py", line 76, in Database
    _get_directory = nmlib.notmuch_database_get_directory_b0rked
  File "/usr/lib/python2.7/ctypes/__init__.py", line 378, in __getattr__
    func = self.__getitem__(name)
  File "/usr/lib/python2.7/ctypes/__init__.py", line 383, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: /home/teythoon/repos/notmuch/lib/libnotmuch.so.3: undefined symbol: notmuch_database_get_directory_b0rked

Justus

Re: Can't compile notmuch-delivery

[David Bremner]

Justus Winter <4winter@informatik.uni-hamburg.de> writes:

>
> I like the idea. The thing with the python bindings is that building
> them wont detect any errors, one has to import the module. Quick and
> dirty python oneliner that doesn't even require installing the
> bindings:

I guess the tests alreedy do at least this much for the python bindings
right?  I think that suffices; I never push without running the tests
first, and the release process automatically runs them. So I think
you're done, as far as minimal sanity checking of the python bindings
goes.

d

Re: Can't compile notmuch-delivery

[Felipe Contreras]

On Fri, Jun 1, 2012 at 8:17 PM, David Bremner <david@tethera.net> wrote:
> Jameson Graef Rollins <jrollins@finestructure.net> writes:
>
>> I don't know, but this is one of the reasons I'm against having
>> "contrib" stuff in the notmuch repo.  If it's not part of the stuff
>> we're willing to release in source tarballs or binary packages then it
>> should probably be in a separate repo.
>
> Just to be clear, ./contrib currently is in the source tarballs, and at
> least notmuch-mutt is included in a binary package for debian.
>
> I don't disagree that status is kindof odd, but I don't see the stuff in
> contrib as being that different in practice from the bindings. In both
> cases we have had incidences of bitrot. The python bindings are
> currently not a problem, but both the ruby and go bindings stopped
> working at all recently.

I see these as different issues: ruby bindings not working because of
a change in the ruby bindings is understandable, but ruby bindings not
working because of an API change *and* that nobody bothered to
implement this change would not make sense to me. Maybe ruby
maintainers don't have that much time, which is why they don't make so
many changes; but the bindings still work, and if somebody has the
time to make changes, well, he has the time, but forcing the issue
when breaking API does not make sense.

I don't see why it would be difficult to do the API updates through
all the notmuch code; if we can't update the API through all the code
in a timely manner, how do we hope 3rd party uses would?

If anything it would be an incentive to don't break the API so often;
let's face it, notmuch is not so widely used, and breaking the API is
not going to help things.

Another option is to go the FFmpeg way: create a new function
notmuch_database_open2, mark the old one as deprecated (but still
works), and only after some time obsolete it.

Cheers.

-- 
Felipe Contreras

Re: Can't compile notmuch-delivery

[Adam Wolfe Gordon]

On Fri, Jun 1, 2012 at 11:01 AM, Jameson Graef Rollins
<jrollins@finestructure.net> wrote:
> On Fri, Jun 01 2012, David Bremner <david@tethera.net> wrote:
>> I guess we should clarify what it means to accept some code into
>> contrib. Do we accept to maintain it even after the original contributor
>> loses interest?
>
> I don't know, but this is one of the reasons I'm against having
> "contrib" stuff in the notmuch repo.  If it's not part of the stuff
> we're willing to release in source tarballs or binary packages then it
> should probably be in a separate repo.

+1.

I think having the bindings in the tree and including them in build
system is reasonable, since they're interfaces into the core of the
notmuch library. We should be careful of what bindings we accept in to
the tree (I don't want to fix Fortran bindings ;-) ), but the small
set we have seems maintainable.

It's harder to make a case for contrib. Keeping stuff that relies on
notmuch up-to-date is a nice idea, but doing so creates more work for
developers working on the library and core, since they have to fix a
bunch of code they're not that familiar with. Things that are actively
used (e.g. alot) will be updated quickly anyway since their developers
will tend to keep up with what notmuch is doing.

-- Adam

Re: Can't compile notmuch-delivery

[Jostein Gogstad]

Tomi Ollila wrote, on Fri, Jun 01, 2012 at 09:44:36AM +0300:
> Yes, commit 5fddc07d (*) changes notmuch_database_open() interface. Austin
> or Ali may fix that some day...

Too bad that commit is included in release 0.13 then :/

-- 
Jostein

Re: Can't compile notmuch-delivery

[Jostein Gogstad]

Ehrm, didn't notice there was a thread here. Never mind the reply.

Jostein Gogstad wrote, on Mon, Jun 04, 2012 at 09:02:25AM +0200:
> Tomi Ollila wrote, on Fri, Jun 01, 2012 at 09:44:36AM +0300:
> > Yes, commit 5fddc07d (*) changes notmuch_database_open() interface. Austin
> > or Ali may fix that some day...
> 
> Too bad that commit is included in release 0.13 then :/
> 
> -- 
> Jostein

-- 
Jostein