makefile regression

makefile regression

[Greg Troxel]

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


For a long time, I've been updating org from git every week or two via:

  update-org () {
      (cd $HOME/SOFTWARE/EMACS/org-mode && git pull && make)
  }

and I have emacs pointed at that directory.   This is on NetBSD where
"make" is BSD make.

Today, I updated again and got:

  make: "/home/gdt/SOFTWARE/EMACS/org-mode/Makefile" line 6: Need an operator
  make: "/home/gdt/SOFTWARE/EMACS/org-mode/Makefile" line 87: Need an operator
  make: Fatal errors encountered -- cannot continue

  make: stopped in /home/gdt/SOFTWARE/EMACS/org-mode

and it seems recent changes have required beyond-POSIX-make features.

This seems unfortunate; I don't understand why building org has to be so
complicated.  If it is complicated, it seems best to use
autoconf/automake, which already have worked out most of the portability
issues.

At the very least a dependency on GNU make should be documented, if that
is indeed an intentional decision by the community.   (I haven't seen
any discussion, but I confess to not quite keeping up with with
emacs-orgmode traffic.)

Greg


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

Re: makefile regression

[Bastien]

Hi Greg,

Greg Troxel <gdt@ir.bbn.com> writes:

> For a long time, I've been updating org from git every week or two via:
>
>   update-org () {
>       (cd $HOME/SOFTWARE/EMACS/org-mode && git pull && make)
>   }
>
> and I have emacs pointed at that directory.   This is on NetBSD where
> "make" is BSD make.
>
> Today, I updated again and got:
>
>   make: "/home/gdt/SOFTWARE/EMACS/org-mode/Makefile" line 6: Need an operator
>   make: "/home/gdt/SOFTWARE/EMACS/org-mode/Makefile" line 87: Need an operator
>   make: Fatal errors encountered -- cannot continue
>
>   make: stopped in /home/gdt/SOFTWARE/EMACS/org-mode
>
> and it seems recent changes have required beyond-POSIX-make features.
>
> This seems unfortunate; I don't understand why building org has to be so
> complicated.  

It does *not* have to be.

> If it is complicated, it seems best to use
> autoconf/automake, which already have worked out most of the portability
> issues.
>
> At the very least a dependency on GNU make should be documented, if that
> is indeed an intentional decision by the community.   (I haven't seen
> any discussion, but I confess to not quite keeping up with with
> emacs-orgmode traffic.)

I will let Achim reply to your issue here.  I agree we should stick to
something as simple and portable as possible.  We will document all the
changes in this area for the 7.9 release.

Best,

-- 
 Bastien

Re: makefile regression

[Achim Gratz]

Greg Troxel writes:
> and it seems recent changes have required beyond-POSIX-make features.

GNU make is (and actually always was) required for the Makefile to fully
work.

> This seems unfortunate; I don't understand why building org has to be so
> complicated.  If it is complicated, it seems best to use
> autoconf/automake, which already have worked out most of the portability
> issues.

Please, let's not go there.  I will implement a facility to build an
in-place orgmode without any support from make at all.  It appears that
this would be enough for your use-case, but I'd still still suggest to
use GNU make.

> At the very least a dependency on GNU make should be documented, if that
> is indeed an intentional decision by the community.

At the very start of my Makefile branch I stated that I will use GNU
make since the old make file already used some GNU make features.  This
will be documented when it gets released.  Using GNU make features
helped to keep things a bit more maintenance friendly, but before other
things, I have a reliable documentation of what it is supposed to do and
can be reasonably sure that it actually does that across a range of
platforms.

> (I haven't seen any discussion, but I confess to not quite keeping up
> with with emacs-orgmode traffic.)

It seems a better idea to stay on maint rather than on master then.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: makefile regression

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> At the very start of my Makefile branch I stated that I will use GNU
> make since the old make file already used some GNU make features.  This
> will be documented when it gets released.

FWIW, Achim's work on the makefile will be part of Org 7.9, expected to
be released in June (I'm ending a contract at the end of this month, so
I will have more time in June.)

Part of the reasons why Org 7.9 has been delayed is (1) the work
required to make Org 7.8.* part of Emacs 24.1 and (2) because I thought
it would be weird to release 7.9 while the next Emacs will have 7.8.*.
So I didn't rush on releasing 7.9.  But since there is no official date
for Emacs 24.1, Org 7.9 might be released before it anyway.

-- 
 Bastien

Re: makefile regression

[Greg Troxel]

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


I don't really object to using GNU make; enough things require it
(probably emacs does too) that it's already installed.  It's more that
"anyone using a makefile will use gnu make" isn't a valid assumption,
especially when the documentation says "type make".

  At the very start of my Makefile branch I stated that I will use GNU
  make since the old make file already used some GNU make features.  This
  will be documented when it gets released.  Using GNU make features
  helped to keep things a bit more maintenance friendly, but before other
  things, I have a reliable documentation of what it is supposed to do and
  can be reasonably sure that it actually does that across a range of
  platforms.

It seems easy enough to document the requirement in README in the
sources, where programs traditonally list their prerequisites; I looked
there and in the usual other files and found no such requirement
explained.  I don't understand why it makes sense to defer adjusting the
source to explain what's needed until its tagged, but maybe you don't
mean that.

Separately, that would be a good place to explain what version of emacs
are supported.  I am running 24 and thus not running into too new/old,
but I now realize that's an obvious question the answer to which my
attempt to find out if the requirement to use GNU Make was documented
should have led me across.

  > This seems unfortunate; I don't understand why building org has to be so
  > complicated.  If it is complicated, it seems best to use
  > autoconf/automake, which already have worked out most of the portability
  > issues.

  Please, let's not go there.  I will implement a facility to build an
  in-place orgmode without any support from make at all.  It appears that
  this would be enough for your use-case, but I'd still still suggest to
  use GNU make.

I did use GNU make.   My reaction was not to GNU make, but that it
wasn't obvious in a minute or two what all the makefile complexity was
for.

  > (I haven't seen any discussion, but I confess to not quite keeping up
  > with with emacs-orgmode traffic.)

  It seems a better idea to stay on maint rather than on master then.

By not quite keeping up I mean that I scan all the subject lines and
read some things.  Almost all if not all of my problems on master over
the last few years have been running into real bugs.


Thanks,
Greg

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

Re: makefile regression

[Achim Gratz]

Greg Troxel writes:
> I don't really object to using GNU make; enough things require it
> (probably emacs does too) that it's already installed.  It's more that
> "anyone using a makefile will use gnu make" isn't a valid assumption,
> especially when the documentation says "type make".
[...]

Could you please state clearly what you want to have changed and
possibly how?  You keep wandering back and forth in your arguments, but
to me it seems simply adding a sentence or two to the README file about
the need for GNU make would suffice until the full documentation is
finished.  I'm sure Bastien would appreciate if you could supply a patch
for it.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

[PATCH] Add section describing prerequisites.

[Greg Troxel]

Note that building org requires GNU make, and that 3.82 is known to
work.

Begin to list the versions of emacs that org can work with.  (It seems
clear taht some versions of XEmacs work, but I couldn't find out
which.)
---
 README |   13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/README b/README
index 6fcddb9..5fee08e 100644
--- a/README
+++ b/README
@@ -40,3 +40,16 @@ request-assign-future.txt
 
 EXPERIMENTAL
     Experimental code, not necessarily FSF copyright.
+
+--------------------
+
+Prerequisites for building and using org:
+
+ - GNU make.  Version 3.82 is known to work, but earlier versions are
+   likely ok.
+
+ - emacs, one of
+     GNU emacs 22
+     GNU emacs 23
+     GNU emacs (what will be 24)
+     ?
-- 
1.7.10.2

Re: [PATCH] Add section describing prerequisites.

[Bastien]

Hi Greg,

Greg Troxel <gdt@ir.bbn.com> writes:

> Note that building org requires GNU make, and that 3.82 is known to
> work.

Thanks for this.  I've been minimalist:

  http://orgmode.org/w/?p=org-mode.git;a=commit;h=0103d1

I don't want to update the README file each time a new version of 
GNU Make is released and known to work.

> Begin to list the versions of emacs that org can work with.  (It seems
> clear taht some versions of XEmacs work, but I couldn't find out
> which.)

Stating that Emacs is needed to an Emacs library is pretty obvious.

Listing the oldest Emacs and XEmacs versions is more useful, but we
need to be more precise: can someone tell me what is the oldest Emacs
version the current master is running fine with?  Same for XEmacs?

Thanks,

-- 
 Bastien

Re: [PATCH] Add section describing prerequisites.

[Greg Troxel]

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


Bastien <bzg@gnu.org> writes:

>   http://orgmode.org/w/?p=org-mode.git;a=commit;h=0103d1
>
> I don't want to update the README file each time a new version of 
> GNU Make is released and known to work.

Understood - what I meant was to have the oldest version that was
needed, but I suspect that while org needs GNU make, anything from the
last 5 years is ok, so it's not important.

>> Begin to list the versions of emacs that org can work with.  (It seems
>> clear taht some versions of XEmacs work, but I couldn't find out
>> which.)
>
> Stating that Emacs is needed to an Emacs library is pretty obvious.

agreed, but

> Listing the oldest Emacs and XEmacs versions is more useful, but we
> need to be more precise: can someone tell me what is the oldest Emacs
> version the current master is running fine with?  Same for XEmacs?

yes, proking that knowledge was my intent.


Thanks for adjusting the docs.
Greg

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

Re: makefile regression

[Greg Troxel]

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


Achim Gratz <Stromeko@nexgo.de> writes:

> Could you please state clearly what you want to have changed and
> possibly how?  You keep wandering back and forth in your arguments, but

What I meant was:

  If GNU make is required it needs to be documented.

  Separately from that, the makefiles look much more complicated than I
  would have thought necessary, and if there aren't good reasons to
  require more than POSIX make, it would be nice to stay with POSIX.

> to me it seems simply adding a sentence or two to the README file about
> the need for GNU make would suffice until the full documentation is
> finished.  I'm sure Bastien would appreciate if you could supply a patch
> for it.

Fair enough - I have sent a patch which adds to the README the kind of
information present in almost all other software pacakges.  It needs
adjusting to list the XEmacs versions that org can use, but I think it's
close.

Thanks,
Greg



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

Re: makefile regression

[Achim Gratz]

Greg Troxel writes:
> If GNU make is required it needs to be documented.

I've added a comment into Makefile as a stopgap measure.

> Separately from that, the makefiles look much more complicated than I
> would have thought necessary, and if there aren't good reasons to
> require more than POSIX make, it would be nice to stay with POSIX.

Last I looked it didn't seem possible to achieve the functionality of
the build system without resorting to generated makefiles, which would
either imply the use of further external tools or yet another make
flavor.  In light of the fact that orgmode was already using GNU make
extensions, it seemed more prudent to use GNU make extensions to a
fuller extent.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables