Re: [O] makefile regression
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
Re: [O] makefile regression
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: [O] makefile regression
Achim Gratz strom...@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: [O] makefile regression
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 pgpolfsUCxVvp.pgp Description: PGP signature
Re: [O] makefile regression
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
Re: [O] makefile regression
Achim Gratz strom...@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 pgpL5rV59TuiV.pgp Description: PGP signature
[O] makefile regression
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
pgpHzFWcj8zFH.pgp
Description: PGP signature
Re: [O] makefile regression
Hi Greg,
Greg Troxel g...@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
