Re: [O] Makefile restructuring
Hi Achim, Achim Gratz strom...@nexgo.de writes: Bastien writes: Please test this and report any problem while using make to install Org. Here's another refinement to make oldorg the default target unless local.mk is actively edited by the user. Applied, thanks. -- Bastien
Re: [O] Makefile restructuring
Bastien writes: Please test this and report any problem while using make to install Org. Here's another refinement to make oldorg the default target unless local.mk is actively edited by the user. If you already have a local.mk file and would like this behaviour, just insert the following on the first line of local.mk: --8---cut here---start-8--- oldorg: --8---cut here---end---8--- With this patch, the new Makefile produces the same results out-of-the box as the old one (modulo the bugs that got fixed: no need for a make clean unless you do something really unusual). The patch also adds a new target uncompiled that will remove any compiled lisp files that may be around and just creates the autoloads. If you fancy uncompiled installation, insert this as the first line to local.mk: --8---cut here---start-8--- uncompiled: --8---cut here---end---8--- This will enable a plain and simple make to do what you want without taking anything away. If you'd rather do something else with a plain make, you can add your own target definitions there as well (the first one will always be the default target): --8---cut here---start-8--- fancy: help info uncompiled fancy-install: help install-info install-lisp help:: $(info My fancyness) $(info ) $(info ) $(info fancy - show help, update doc and autoloads) --8---cut here---end---8--- In this case, plain make would do fancy and you'd have a new target fancy install plus a documentation for these when doing a make help, make targets or make helpall. The patch: From f9f0c7b4e367259bafac1cb5cbec17dd2cff625a Mon Sep 17 00:00:00 2001 From: Achim Gratz strom...@stromeko.de Date: Wed, 25 Apr 2012 19:04:29 +0200 Subject: [PATCH] Improve compatibility with old Makefile * targets.mk: change the local.mk template so that oldorg will be the default target for maximum compatibility. Admonish info message with a reminder to use make help for more information on targets and that oldorg is the default target for now. Add new convenience target uncompiled that will keep the lisp directory free from *.elc files and the autoload files up-to-date. * Makefile: make targets and helpall depend on help so that only help:: or helpall:: needs to be written for adding more help messages. Useful when users want to add their own messages to make help et al. --- Makefile | 14 -- targets.mk | 17 +++-- 2 files changed, 19 insertions(+), 12 deletions(-) diff --git a/Makefile b/Makefile index 1258d52..66a637c 100644 --- a/Makefile +++ b/Makefile @@ -10,8 +10,10 @@ all:: # Describe valid make targets for org-mode. -.PHONY: targets help -targets help helpall:: +.PHONY: targets help helpall +targets: help +helpall:: help +help:: $(info ) $(info Getting Help) $(info ) @@ -61,18 +63,18 @@ helpall:: $(info ) $(info Documentation) $(info =) -targets help helpall:: +help:: $(info make doc - build all documentation) helpall:: $(info make docs - dito) -targets help helpall:: +help:: $(info make info - build Info documentation) helpall:: $(info make html - build HTML documentation) $(info make pdf - build PDF documentation) $(info make card - build reference cards) $(info make refcard - dito) -targets help helpall:: +help:: $(info ) $(info Installation) $(info ) @@ -81,7 +83,7 @@ helpall:: $(info make install-etc - build and install files in /etc) $(info make install-lisp - build and install Org Elisp files) $(info make install-info - build and install Info documentation) -targets help helpall:: +help:: @echo include targets.mk # toplevel make machinery diff --git a/targets.mk b/targets.mk index e208ad7..4ad5c5f 100644 --- a/targets.mk +++ b/targets.mk @@ -25,19 +25,24 @@ endif check test install info html pdf card doc docs $(INSTSUB) \ autoloads cleanall clean cleancontrib cleanrel clean-install \ cleanelc cleandirs cleanlisp cleandoc cleandocs cleantest \ - compile compile-dirty + compile compile-dirty uncompiled -oldorg: compile autoloads info # what the old makefile did when no target was specified +oldorg: compile autoloads info # what the old makefile did when no target was specified +uncompiled: cleanlisp autoloads # for developing refcard: card update update2:: up0 all .PRECIOUS: local.mk local.mk: - $(info ==) - $(info Created a local.mk template.) - $(info Please adapt local.mk to your local setup!) - $(info ==) + $(info ==) + $(info = Invoke make help for a synopsis of make
Re: [O] Makefile restructuring
Hi Achim, On Sun, Apr 22, 2012 at 17:34, Achim Gratz strom...@nexgo.de wrote: suvayu ali writes: The above recipe works. But just make, leaves the working tree without lisp/org-install.el. From the log I see it explicitly deletes it, but doesn't generate it again. A subsequent make autoloads is required to get a working org setup. Is this expected behaviour? This is intentional. The autoloads are generated just before installing, since that's where they are needed. I really don't want to encourage further use of the git worktree as the org installation, although it sort of works if you do a make autoloads. Thanks for the clarifications. :) You can now easily keep multiple installations within the org directory if so desired (I do this myself for testing). Using the worktree instead can lead to very hard to track bugs when the autoload files get out of sync with the sources. This is the reason I always remove them before compilation and I should probably remove them just after installation as well. Okay I'll try this out. -- Suvayu Open source is the future. It sets us free.
Re: [O] Makefile restructuring
Samuel Wales writes: make cleanall still has the pdf errors. Perhaps you don't need that anymore even for oldorg. You don't need cleanall anymore, but that's nevertheless a bug. Fixed. make oldorg compiles but still has the info error. I've added a customization for specifying which (if any) documentation should be made by default. If you set ORG_MAKE_DOC = info in local.mk, then you can use all the convenience targets (like update or up2) without the need for texi2pdf. Please check again when Bastien has applied those changes to master. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Makefile restructuring
Hi Achim, Last time when I tested the latest changes, I overlooked something. On Sat, Apr 21, 2012 at 16:34, Achim Gratz strom...@nexgo.de wrote: If you don't install org (i.e. run it directly out of the Git worktree), that would be: make compile autoloads info The above recipe works. But just make, leaves the working tree without lisp/org-install.el. From the log I see it explicitly deletes it, but doesn't generate it again. A subsequent make autoloads is required to get a working org setup. Is this expected behaviour? I thought a simple make should cleanly compile Org ELisp files and documentation? Thanks for any comments. -- Suvayu Open source is the future. It sets us free.
Re: [O] Makefile restructuring
On 2012-04-21, Achim Gratz strom...@nexgo.de wrote: make oldorg compiles but still has the info error. I've added a customization for specifying which (if any) documentation should be made by default. If you set ORG_MAKE_DOC = info in local.mk, then you can use all the convenience targets (like update or up2) without the need for texi2pdf. The info error is an info error, not a texi2pdf nonexistence error. I posted a message with the error output. Perhaps your makefiles can check for the existence of possible errors first? -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Re: [O] Makefile restructuring
suvayu ali writes: The above recipe works. But just make, leaves the working tree without lisp/org-install.el. From the log I see it explicitly deletes it, but doesn't generate it again. A subsequent make autoloads is required to get a working org setup. Is this expected behaviour? This is intentional. The autoloads are generated just before installing, since that's where they are needed. I really don't want to encourage further use of the git worktree as the org installation, although it sort of works if you do a make autoloads. You can now easily keep multiple installations within the org directory if so desired (I do this myself for testing). Using the worktree instead can lead to very hard to track bugs when the autoload files get out of sync with the sources. This is the reason I always remove them before compilation and I should probably remove them just after installation as well. I thought a simple make should cleanly compile Org ELisp files and documentation? Which is what it does. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Makefile restructuring
Samuel Wales writes: The info error is an info error, not a texi2pdf nonexistence error. I posted a message with the error output. The output you posted wasn't an error message. Make informs you that it has been told to build something and then determined that the target in question was already fully up-to-date (none of the sources have changed), so it actually didn't need to do anything. I don't suppress this output since it is telling you something useful. Since I now unconditionally update the include file which contains the org version, you will not see that message again on current master. The info file will always be re-generated. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Makefile restructuring
Bastien writes: Please test this and report any problem while using make to install Org. A few notes based on the feedback here and off-list: The change of org-version was intended to show a complete version string regardless of the place of installation and give a hint of where the autoloads actually come from — it was showing the Git version only when installed inside the repository before. If you run org directly from inside the work tree (possibly uncompiled, though that is an unrelated matter), please do a make autoloads to get the correct version shown. I am still experimenting to get the current version displayed without an explicit invocation of make if and only if you run org directly from the lisp directory in the worktree. Doing that is not really difficult (as the old implementation showed), having it work correctly in all situations is another matter; finally I don't want that part of the code active in an installed version even when it is inside the repository, so that it always shows the version that is installed and not one that currently happens to be checked out. I'll probably provide a new make target for setting the work tree up for that (you'll only have to use that once), not sure yet what a good name is for that. I currently see no way of running org directly without generating and loading the org-install.el — doing so appears to work unfortunately, but it actually relies on the autoload forms that have been supplied with the org version that comes with Emacs (which will subtly or not so subtly break depending on how far out of sync the version in Emacs is with the version in Git). So folks who use the Git repository but not make would currently have to generate org-install.el by hand. I'll try to fix that, too — but it'll take a while. If and when I get that done, make will take advantage of it which should take care of keeping things working further down the road. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Makefile restructuring
Achim's branch is now merged in Org's git master branch. Please test this and report any problem while using make to install Org. -- Bastien
Re: [O] Makefile restructuring
Hi, On Sat, Apr 21, 2012 at 12:39, Bastien b...@altern.org wrote: Achim's branch is now merged in Org's git master branch. Please test this and report any problem while using make to install Org. It works great with my setup; compile and use without installing it with other Emacs files. I love the modularity. :) Great work Achim. -- Suvayu Open source is the future. It sets us free.
Re: [O] Makefile restructuring
On 2012-04-21, Bastien b...@altern.org wrote: Please test this and report any problem while using make to install Org. I cannot report in a full way now, but Org does not make at all for me now. I do make cleanall and then make normally. Hope it helps despite the lack of a full report. I am reverting to a previous Org now. The first problem is that it now seems to expect texi2pdf. I can't get it for OS configuration reasons that I cannot fix. This was never a problem before. I tried the following patch, but it did not cause install.elc to be created. So maybe this is a bad fix or maybe there are other problems. Modified default.mk diff --git a/default.mk b/default.mk index 45e6fbf..7d0509c 100644 --- a/default.mk +++ b/default.mk @@ -61,7 +61,7 @@ ELCDIR= $(BATCH) \ ELC= $(BATCH) -f batch-byte-compile # How to make a pdf file from a texinfo file -TEXI2PDF = texi2pdf --batch --clean +TEXI2PDF = echo would do texi2pdf --batch --clean # How to make a pdf file from a tex file PDFTEX = pdftex
Re: [O] Makefile restructuring
Samuel Wales writes: I cannot report in a full way now, but Org does not make at all for me now. I do make cleanall and then make normally. I can't parse that sentence... The first problem is that it now seems to expect texi2pdf. I can't get it for OS configuration reasons that I cannot fix. This was never a problem before. Since all other methods of producing the documentation are not reliable, texi2pdf is the default now and has actually been for a while, independently of my other changes. You can override it if you don't have it, see below. If you don't care about getting all of the documentation, just do a make compile or make compile info, this would then not need texi2pdf at all. I tried the following patch, but it did not cause install.elc to be created. So maybe this is a bad fix or maybe there are other problems. Any adaptations to your local environment should be made in local.mk — that way it is ensured that changes in the defaults do not overwrite your local configuration. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [O] Makefile restructuring
I use Windows and I never got texi2pdf to work properly. I was really stumped because I had no way to test/view my ODT changes in a pdf manual. Finally, I discovered texify. (I use MikTeX) texify --pdf %s So you can use this as the default setting or hint at this possibility (with a commented line) in your platform specific config file (if you have one). --
Re: [O] Makefile restructuring
Hi Achim, On 2012-04-21, Achim Gratz strom...@nexgo.de wrote: Samuel Wales writes: I cannot report in a full way now, but Org does not make at all for me now. I do make cleanall and then make normally. I can't parse that sentence... Org broke. Due to make. Somehow. Since all other methods of producing the documentation are not reliable, texi2pdf is the default now and has actually been for a while, independently of my other changes. You can override it if you don't have it, see below. If you don't care about getting all of the documentation, just do a make compile or make compile info, this would then not need texi2pdf at all. I do not need pdf. I do need info. Are you saying I need to stop doing this: make cleanall;make And start doing this instead: make compile info ? Will that make org-install and also info? If so, what happens when makefiles change again and I will start missing something because I don't have it on the make line? Plain make worked before and would make anything new that people would add to the makefile. Is there a way to just get it to work the way it did before? Any adaptations to your local environment should be made in local.mk — that way it is ensured that changes in the defaults do not overwrite your local configuration. I have no idea of how to do this whatsoever. Hints appreciated. All I want is for Org to work as it did before. Thanks.
Re: [O] Makefile restructuring
Achim's branch is now merged in Org's git master branch. Please test this and report any problem while using make to install Org. -- Bastien It runs smoothly for me, using make clean, make, make doc, and make install (without local.mk, having yet no need of it). François.
Re: [O] Makefile restructuring
Samuel Wales writes: make compile info Will that make org-install and also info? If you don't install org (i.e. run it directly out of the Git worktree), that would be: make compile autoloads info If so, what happens when makefiles change again and I will start missing something because I don't have it on the make line? Plain make worked before and would make anything new that people would add to the makefile. Plain make now really makes everything except install as it is supposed to do (that is equivalent to make all). It didn't do the full documentation before. Is there a way to just get it to work the way it did before? That would be an uphill battle. You can define your own target for what you want to do in local.mk, say org and then do make org. BTW, you don't need cleanall anymore before compiling (it is now implicit); if you really want to compile without cleaning first, do a compile-dirty. Any adaptations to your local environment should be made in local.mk — that way it is ensured that changes in the defaults do not overwrite your local configuration. I have no idea of how to do this whatsoever. You just create a file local.mk, copy in the definitions from default.mk that you need to change (and only those) and then change them to suit your environment. Look up the examples posted earlier in this thread: http://article.gmane.org/gmane.emacs.orgmode/44567 You'd additionally want ---8-8--- .PHONY: org org:compile autoloads info ---8-8--- at the top of your local.mk (that needs to be a TAB after the colon) if you want to be able to say make org and have it do make compile autoloads info. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Makefile restructuring
Samuel Wales writes: Hints appreciated. All I want is for Org to work as it did before. I have just sent a patch to Bastien that makes this more easily possible. You still need a local.mk file then, but you only need to put a line oldorg: in it — I hope that addresses your concern. 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 restructuring
On 2012-04-21, Achim Gratz strom...@nexgo.de wrote: If you don't install org (i.e. run it directly out of the Git worktree), that would be: make compile autoloads info Thanks. I will do this if there isn't a generic do everything except the thing that does not work option. Plain make now really makes everything except install as it is supposed to do (that is equivalent to make all). It didn't do the full documentation before. I checked and I actually did make cleanall;make all before. Thanks. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Re: [O] Makefile restructuring
Achim Gratz strom...@nexgo.de writes: Samuel Wales writes: Hints appreciated. All I want is for Org to work as it did before. I have just sent a patch to Bastien that makes this more easily possible. You still need a local.mk file then, but you only need to put a line oldorg: in it — I hope that addresses your concern. The patch has been applied. -- Bastien
Re: [O] Makefile restructuring
Samuel Wales writes: I checked and I actually did make cleanall;make all before. The all target did in fact not make everything there was to make with the old Makefile, hence the difference in behaviour. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: [O] Makefile restructuring
Hi Achim François Allisson franc...@allisson.co writes: Achim's branch is now merged in Org's git master branch. Please test this and report any problem while using make to install Org. -- Bastien It runs smoothly for me, using make clean, make, make doc, and make install (without local.mk, having yet no need of it). François. Works nicely for me too, and I have a modified local.mk config for multiple Emacs versions and a non-default org location. Note: `make install check' will make, install, and run the tests! Thanks Achim. Best, Martyn
Re: [O] Makefile restructuring
oldorg: did not seem to fix anything. Cleaning and making both resulted in the attempt to make the pdf, which makes it error in both cases. make compile autoloads info now says this: make -C doc info make[1]: Nothing to be done for `info'. Thanks. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Re: [O] Makefile restructuring
Samuel Wales writes: oldorg: did not seem to fix anything. Did you update to the latest version on master before trying? 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 restructuring
On 2012-04-21, Achim Gratz strom...@nexgo.de wrote: Did you update to the latest version on master before trying? Yes. I should say that it's not critical that I get the old way working, and I might even have a way to build info files manually in principle, but it might help others if this new makefile scheme works more smoothly. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Re: [O] Makefile restructuring
Samuel Wales writes: On 2012-04-21, Achim Gratz strom...@nexgo.de wrote: Did you update to the latest version on master before trying? Yes. Then what exactly happens when you do make oldorg? If that is trying to make the PDF, I don't understand what is going on or you may have some local changes that you forgot to indicate. I should say that it's not critical that I get the old way working, and I might even have a way to build info files manually in principle, but it might help others if this new makefile scheme works more smoothly. That's why I'm asking if things are working for you now. If you have a local.mk, please post it's contents (or send it just to me if you don't want to post to the list). Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Makefile restructuring
Martyn Jago writes: Works nicely for me too, and I have a modified local.mk config for multiple Emacs versions and a non-default org location. Note: `make install check' will make, install, and run the tests! Actually, make up2 will update all remotes, do a git pull on the current branch, compile and test and then finally install org all in one go. Once you have set things up the way you like, that's the fastest way to keep current. The real advantage however is that if there happens to be an error someplace, make is smart enough to stop right there and not install a not-quite working org over an older, but working version. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Makefile restructuring
Le samedi 21 avr 2012 à 20:30:49 (+0200), Achim Gratz a écrit : Martyn Jago writes: Works nicely for me too, and I have a modified local.mk config for multiple Emacs versions and a non-default org location. Note: `make install check' will make, install, and run the tests! Actually, make up2 will update all remotes, do a git pull on the current branch, compile and test and then finally install org all in one go. Once you have set things up the way you like, that's the fastest way to keep current. The real advantage however is that if there happens to be an error someplace, make is smart enough to stop right there and not install a not-quite working org over an older, but working version. Thanks Martyn and Achim for hints on make install check and make up2. The latter is exactly what I needed. Achim's restructuring made me just realise the utility and power of these Makefile rules... It's so nice to learn by using org. Best, François.
Re: [O] Makefile restructuring
On 2012-04-21, Achim Gratz strom...@nexgo.de wrote: Then what exactly happens when you do make oldorg? If that is trying to make the PDF, I don't understand what is going on or you may have some local changes that you forgot to indicate. I ran make all, as I did not realize that you wanted me to do otherwise. :) make cleanall still has the pdf errors. Perhaps you don't need that anymore even for oldorg. make oldorg compiles but still has the info error. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Re: [O] Makefile restructuring
On 2012-04-21, François Allisson franc...@allisson.co wrote: Actually, make up2 will update all remotes, do a git pull on the current branch, compile and test and then finally install org all in one go. Once you have set things up the way you like, that's the fastest way to keep current. The real advantage however is that if there happens to be an error someplace, make is smart enough to stop right there and not install a not-quite working org over an older, but working version. Wow! Is update the same thing without the install part? (Now I want this :), but I'm guessing the pdf and info problems would occur with it?) -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Re: [O] Makefile restructuring
Achim Gratz strom...@nexgo.de writes: Hi Achim Martyn Jago writes: Works nicely for me too, and I have a modified local.mk config for multiple Emacs versions and a non-default org location. Note: `make install check' will make, install, and run the tests! Actually, make up2 will update all remotes, do a git pull on the current branch, compile and test and then finally install org all in one go. Once you have set things up the way you like, that's the fastest way to keep current. The real advantage however is that if there happens to be an error someplace, make is smart enough to stop right there and not install a not-quite working org over an older, but working version. Regards, Achim. Very good! Is it documented? Love it. Best, Martyn
Re: [O] Makefile restructuring
Some recent changes to this fork: - integrated the etc/ directory for Jambunathans ODT exporter - allow for optional local customization (local.mk) in lisp/ and /etc - use byte-recompile-directory by default (much faster and closer to what package manager does); always make clean and remove dependencies since they don't work anyway and can't be auto-generated - version strings are compiled into org-install.el so that they don't need to be commited into org.el - git version is always shown when available (otherwise N/A when uncompiled and not in a git repository) - show the path to org-install in org-version to make it easier to check for possible load-path corruption due to duplicate or stale installations Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Makefile restructuring
Achim Gratz strom...@nexgo.de writes: If byte-compile-directory is available in all versions of Emacs, then I could certainly use it in the Makefile. Not sure if I can get to it before the weekend, but I will try it out soon-ish. I've pushed a change to my Makefile fork that uses batch-byte-recompile-directory, which in turn calls the equivalent of what package manager uses. As a bonus it now compiles much faster since it only starts up Emacs once. I may be missing what the org-macs.el issue is, precisely. There shouldn't be any differences between Makefiles and package managers results now, aside from the fact that one of these runs in batch-mode and the other not (I think). Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Makefile restructuring
A more complete recipe for setting up a tracking branch to a remote branch in git (assuming you've already cloned orgmode.git locally and have a clean working directory): $ git remote add -t Makefile remote-tableheadings git://repo.or.cz/org-mode/org-tableheadings.git $ git fetch remote-tableheadings Makefile:local-Makefile $ git checkout local-Makefile $ git branch --track local-Makefile remote-tableheadings/Makefile $ git config branch.local-Makefile.rebase true Whenever you want to get changes from upstream, do a $ git pull When you just want to check if there are changes, do a $ git remote update $ git status HTH, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Makefile restructuring
Achim Gratz strom...@nexgo.de writes: A more complete recipe for setting up a tracking branch to a remote branch in git (assuming you've already cloned orgmode.git locally and have a clean working directory): ...which doesn't really work since I did a few experiments in the clone and messed up the recipe by not checking the already existing configuration. So when you get the error message at step 4 you can salvage it with: $ git remote update $ git branch --set-upstream local-Makefile remote-tableheadings/Makefile $ git config branch.local-Makefile.rebase true In a fresh clone that does not have pre-existing definitions and configurations, this would be the right thing to do (and is a bit shorter): $ git remote add -t Makefile remote-tableheadings git://repo.or.cz/org-mode/org-tableheadings.git $ git remote update $ git branch --track local-Makefile remote-tableheadings/Makefile $ git config branch.local-Makefile.rebase true $ git checkout local-Makefile I tested it on a completely fresh clone this time. :-) Sorry for the confusion Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [O] Makefile restructuring
Jambunathan K kjambunat...@gmail.com writes: If we reconcile what happens here with what is done in Makefile, may be we can uncover why certain macros in org-macs.el doesn't propagated to some set of files. If byte-compile-directory is available in all versions of Emacs, then I could certainly use it in the Makefile. Not sure if I can get to it before the weekend, but I will try it out soon-ish. Note that org-macs.el issue is increasingly reported only with emacs-23 and not with emacs-24. One of the reason could be that emacs-24 *already* has most of the macro definitions in the system path. This is not the case with emacs-23 installations which have (much?) older versions of org. I may be missing what the org-macs.el issue is, precisely. From what I understand package manager compiles files in alphabetical order. It means that org-macs.el gets compiled after org-agenda.el. With make (at least after make clean) it's exactly the same thing. What I don't understand is if package manager uses the already customized load-path or the bog-standard one, like make does via emacs -Q. Also when eval-when-compile is done of org-macs.el - somewhere it should be done right? - I don't know which of the org-macs.el gets loaded. Is it system-installed one or the one in the distribution tar. That would depend on which one it finds first, hence the question of what load-path looks like at that point. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Makefile restructuring
Recent changes in my Makefile fork: org-version has been changed to always get the version information from org-install.el. This way, there is no need to invoke a shell in org-version or to keep any version information in org.el. Additionally org-version checks where it finds org-install.el and reports the full path so that it should be easier to spot when the load-path has been set up wrongly and/or the (newer) installation of org is missing org-install.el, but it is reachable in an older installation. I've added a target compile-dirty that doesn't include the invocation of make clean so that it is easier to test small changes that only change a single file. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Makefile restructuring
FYI, if Org is insalled through the package manager there is no org-install.el. Package manager creates autoloads on it's own and names it org-autoloads.el. I believe, for most part, org-install and org-autoloads have the same functionality. Recent changes in my Makefile fork: org-version has been changed to always get the version information from org-install.el. This way, there is no need to invoke a shell in org-version or to keep any version information in org.el. Additionally org-version checks where it finds org-install.el and reports the full path so that it should be easier to spot when the load-path has been set up wrongly and/or the (newer) installation of org is missing org-install.el, but it is reachable in an older installation. I've added a target compile-dirty that doesn't include the invocation of make clean so that it is easier to test small changes that only change a single file. Regards, Achim. --
Re: [O] Makefile restructuring
Jambunathan K kjambunat...@gmail.com writes: FYI, if Org is insalled through the package manager there is no org-install.el. Package manager creates autoloads on it's own and names it org-autoloads.el. I believe, for most part, org-install and org-autoloads have the same functionality. Then maybe they should have the same name, but surely they should be produced by the same method. Can you point me to a documentation (or source) that details how the package manager deals with the autoloads? It shouldn't be too difficult to use the same method in the Makefile once I understand how it's done. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Makefile restructuring
Achim Gratz strom...@nexgo.de writes: Jambunathan K kjambunat...@gmail.com writes: FYI, if Org is insalled through the package manager there is no org-install.el. Package manager creates autoloads on it's own and names it org-autoloads.el. I believe, for most part, org-install and org-autoloads have the same functionality. Then maybe they should have the same name, but surely they should be produced by the same method. Can you point me to a documentation (or source) that details how the package manager deals with the autoloads? It shouldn't be too difficult to use the same method in the Makefile once I understand how it's done. This is what I see in package.el. --8---cut here---start-8--- (defun package-unpack (name version) (let* ((dirname (concat (symbol-name name) - version)) (pkg-dir (expand-file-name dirname package-user-dir))) (make-directory package-user-dir t) ;; FIXME: should we delete PKG-DIR if it exists? (let* ((default-directory (file-name-as-directory package-user-dir))) (package-untar-buffer dirname) (package-generate-autoloads (symbol-name name) pkg-dir) (let ((load-path (cons pkg-dir load-path))) (byte-recompile-directory pkg-dir 0 t) (defun package-generate-autoloads (name pkg-dir) (require 'autoload) ;Load before we let-bind generated-autoload-file! (let* ((auto-name (concat name -autoloads.el)) (ignore-name (concat name -pkg.el)) (generated-autoload-file (expand-file-name auto-name pkg-dir)) (version-control 'never)) (unless (fboundp 'autoload-ensure-default-file) (package-autoload-ensure-default-file generated-autoload-file)) (update-directory-autoloads pkg-dir))) --8---cut here---end---8--- If we reconcile what happens here with what is done in Makefile, may be we can uncover why certain macros in org-macs.el doesn't propagated to some set of files. Note that org-macs.el issue is increasingly reported only with emacs-23 and not with emacs-24. One of the reason could be that emacs-24 *already* has most of the macro definitions in the system path. This is not the case with emacs-23 installations which have (much?) older versions of org. From what I understand package manager compiles files in alphabetical order. It means that org-macs.el gets compiled after org-agenda.el. Also when eval-when-compile is done of org-macs.el - somewhere it should be done right? - I don't know which of the org-macs.el gets loaded. Is it system-installed one or the one in the distribution tar. These are some of the leading questions that will lead to satisfactory resolution of recently reported issues with package manager. Regards, Achim. --
Re: [O] Makefile restructuring
Michael Brand michael.ch.br...@gmail.com writes:
I have looked into your branch only now. I think it is uncommon for
Makefiles how clean they look now and I appreciate how the Makefile
has been split up plus one is in doc/ and one in lisp/, that there are
no explicit xy.el any more and so on. Thank you for this work.
Thank you for your comments.
Some comments:
There is no @value{DATE}, missing already on master. Would it be ok to
remove setting the DATE or to include it in org.texi like the commit
message subject anticipates?
I don't know why the DATE is currently unused, it looks like it never
was as long as the git repository existed. I expect that when the
Makefile starts to take care of it, it will become more useful. I did
not yet change org.texi to keep the changeset minimal.
In the latter case it could be labeled
build date and optionally when available be enriched with release
date, looked up from the git tag when make is running in a git repo
not dirty and if git is installed. Maybe release date could also
become visible in org-version when running from .el in a git repo not
dirty and if git is installed or when running from .elc built with the
same git requirement. Both would help users to be aware of how
outdated their version is and more. These are only suggestions, else
I'm fine with removing DATE.
Right now git-describe.texi is re-built when org.texi changes, but the
date recorded and the git-describe are of the build time/version. I
need to figure out how to get the actual date of the last change plus
the git describe for that. If that doesn't work I will just change it
to always record the build date and version, just like org-version.
I would prefer the file/target name variables.texi instead of
git-describe.texi as git describe is not necessarily involved and must
not be a requirement.
Sure, this is just a first suggestion to demonstrate how it might work.
Did you check this?:
- make info when not in a git repo
No, and currently it probably breaks. But it isn't too difficult to
keep the old file in that case.
- make info when in a git repo but git is not installed
Ditto.
In case the errors are confirmed: My guess is that again you have a
better solution than me and I don't propose a patch yet. (org-version)
uses (file-exists-p (expand-file-name .git dir)) and
(executable-find git) for this.
You are talking about org-version here? That code is not mine (I only
added another defconst to be able to record the version string during
install). I have never tried what happens when not installed and no git
is present... so please if that does indeed break put a patch to master,
as the problem should already be present there. AFAIK the code should
just drop down to no appending the description string.
The default make target has been changed from all to targets help.
Is this standard? I assume that you considered that this can break the
target org-mode of some upper level Makefile from users (and
Emacs?).
GNU Makefile standards ask that a help target be available and that make
without arguments should show the help rather than freak you out with
starting to do something you may not have wanted to do. One could
certainly decide on a different standard if there's a good reason for
that. Again, Emacs has its own, totally unrelated build system.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [O] Makefile restructuring
Hi Achim On Sun, Oct 30, 2011 at 08:33, Achim Gratz strom...@nexgo.de wrote: In case the errors are confirmed: My guess is that again you have a better solution than me and I don't propose a patch yet. (org-version) uses (file-exists-p (expand-file-name .git dir)) and (executable-find git) for this. You are talking about org-version here? I don't consider org-version to be used in the Makefile but assume that the same tests have to be made there. That code is not mine (I only added another defconst to be able to record the version string during install). I have never tried what happens when not installed and no git is present... so please if that does indeed break put a patch to master, as the problem should already be present there. AFAIK the code should just drop down to no appending the description string. No worry, org-version gets along with that. GNU Makefile standards ask that a help target be available and that make without arguments should show the help rather than freak you out with starting to do something you may not have wanted to do. Good to know. I prefer the standard and like that the GNU Makefile default target is standardized this way. Michael
Re: [O] Makefile restructuring
Hi Achim
On Fri, Oct 28, 2011 at 12:00, Achim Gratz strom...@nexgo.de wrote:
As discussed in another thread, the version from git-describe is now
also recorded into the info documentation.
see here for the thread:
http://lists.gnu.org/archive/html/emacs-orgmode/2011-06/msg00054.html
I have looked into your branch only now. I think it is uncommon for
Makefiles how clean they look now and I appreciate how the Makefile
has been split up plus one is in doc/ and one in lisp/, that there are
no explicit xy.el any more and so on. Thank you for this work.
Some comments:
There is no @value{DATE}, missing already on master. Would it be ok to
remove setting the DATE or to include it in org.texi like the commit
message subject anticipates? In the latter case it could be labeled
build date and optionally when available be enriched with release
date, looked up from the git tag when make is running in a git repo
not dirty and if git is installed. Maybe release date could also
become visible in org-version when running from .el in a git repo not
dirty and if git is installed or when running from .elc built with the
same git requirement. Both would help users to be aware of how
outdated their version is and more. These are only suggestions, else
I'm fine with removing DATE.
I would prefer the file/target name variables.texi instead of
git-describe.texi as git describe is not necessarily involved and must
not be a requirement.
Did you check this?:
- make info when not in a git repo
- make info when in a git repo but git is not installed
In case the errors are confirmed: My guess is that again you have a
better solution than me and I don't propose a patch yet. (org-version)
uses (file-exists-p (expand-file-name .git dir)) and
(executable-find git) for this.
The default make target has been changed from all to targets help.
Is this standard? I assume that you considered that this can break the
target org-mode of some upper level Makefile from users (and
Emacs?).
Michael
Re: [O] Makefile restructuring
Is someone still tracks this thread: I'm still working on the fork, recent changes have been the elimination of the dependencies. I've found no simple way to automatically generate them and even then it would have been really difficult to keep Emacs from picking up stale byte-compiled files. While I've developed a way that allowed to remove all .elc files that a new compile would re-create, I deemed it far too hacky to go live. Instead a ``make clean´´ is now implicit with ``make compile´´ so that there should be no problems anymore that are caused by the order of byte-compilation. As discussed in another thread, the version from git-describe is now also recorded into the info documentation. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Makefile restructuring
Achim Gratz strom...@nexgo.de writes: git remote add -t Makefile remote-tableheadings git://repo.or.cz/org-mode/org-tableheadings.git git fetch remote-tableheadings Makefile:local-Makefile git checkout local-Makefile to get it (change remote-tableheadings and local-Makefile to suit your naming conventions for remotes and local branches, respectively). I will be _rebasing_ against master during development, so expect history in this branch to be volatile. This means you'll need to do a git fetch -f remote-tableheadings whenever I've rebased since the branch doesn't fast-forward in this case — which I've just done so it applies cleanly to current master. As always, testers and their comments are welcome. Bastien asked if he might include it in the next release, so if you've been testing/using this please say if it works (or what doesn't). I've tested it myself on Linux and Win7 (Cygwin and MSys), but there are likely quite a few different setups around. * Changes ** GNU make required The previous Makefile already used a bunch of GNU make extensions so this shouldn't be too much of a shock, but I am now using more of them, especially functions. ** Customization Keep your customizations to the old Makefile around (ie. the part with YOU MUST EDIT THE FOLLOWING LINES). The customization will now be done by putting just those lines (or only the lines you want to change plus any comments, really) into a file named local.mk. The default values are now in a file named default.mk, so you can also just copy from default.mk to local.mk and then edit. The defaults have been slightly adapted to work well on most Linux systems and on Cygwin, specifically prefix = /usr/share # was /usr/local/share On these systems you don't need any customization if you are installing to the system-wide Emacs installation. For other uses, here are a few examples: --8---cut here---start-8--- # local.mk Win7/NTemacs EMACS = C:/Freeware/Emacs-24.0.50/bin/emacs prefix = C:/Freeware/Emacs-24.0.50 lispdir = $(prefix)/site-lisp/org --8---cut here---end---8--- --8---cut here---start-8--- # local.mk Linux/Emacs24 EMACS = /usr/local/bin/emacs prefix = /usr/local/share lispdir = $(prefix)/emacs/site-lisp/org --8---cut here---end---8--- --8---cut here---start-8--- # local.mk Linux/Emacs(system) - test EMACS = /usr/bin/emacs prefix = /home/user/org-test lispdir = $(prefix)/lisp/org --8---cut here---end---8--- --8---cut here---start-8--- # local.mk Debian/Emacs(system) INSTALL_INFO = ginstall-info # insist on GNU install-info # even though dpkg install-info works just fine now --8---cut here---end---8--- Keep in mind that all file-paths need to be absolute, specifically you can't use ~ in prefix or lispdir since it is used in a few places where the shell will not expand it. ** Renamed target doc to docs The target doc has been renamed to docs since it clashed with the subdirectory of the same name. ** New target clean-install I've added a new target clean-install that will remove a previous installation of org from the install directories. This removes old files that may have been present in a previous installation, but not used anymore. You should check with make -n clean-install what it tries to do before letting it _really_ remove anything. ** Installing files from contrib The way things work now, any *.el file you put into lisp/ will be compiled together with and installed along with the org files. So if you want to install a particular contrib feature together with org, just copy (or link) it into lisp/. This does not work with subdirectories (for now), you need to make the actual *.el files visible in lisp/. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Makefile restructuring
The ./doc directory is now also handled via a sub-make invocation. Feature-wise the user part should be complete now. I've also patched org.el to provide a placeholder to record which orgmode version has been installed and the installer will patch the installed file with that so that org-version can show it. Currently uses perl to do that, I'll probably change to sed since I don't want to require perl for installation. Some small patches so that changes to the build system do not get recorded in Emacs' ChangeLog. Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [O] Makefile restructuring
Hi Achim, Achim Gratz strom...@nexgo.de writes: Bastien b...@altern.org writes: Okay - I'll follow that branch till the change becomes mature. I've set up the feature branch Makefile in my org-mode clone on repo.or.cz. Assuming you already have orgmode.git cloned (it does not really matter where from), do a git remote add -t Makefile remote-tableheadings git://repo.or.cz/org-mode/org-tableheadings.git git fetch remote-tableheadings Makefile:local-Makefile git checkout local-Makefile to get it (change remote-tableheadings and local-Makefile to suit your naming conventions for remotes and local branches, respectively). I will be _rebasing_ against master during development, so expect history in this branch to be volatile. As always, testers and their comments are welcome. Thanks a lot for this. Here is some feedback: I think the proliferation of *.mk files can confuse the user. Can we try to reduce this to the maximum? Ideally, there will be no *.mk file at all, just one Makefile in which the maintainer can include a maint.mk file that will only live on orgmode.org server (since we are releasing from there.) But maybe you're already heading in this direction, or my suggestion goes against your goal. Thanks for any answer! Best, -- Bastien
Re: [O] Makefile restructuring
Bastien b...@altern.org writes: I think the proliferation of *.mk files can confuse the user. Can we try to reduce this to the maximum? Nothing is set in stone at this point and there will certainly be changes to make sure things are useful both for users and maintainers of org-mode. If something doesn't feel right, it probably isn't and we can try something else before commiting to any changes. Since this depends on getting feedback, please keep it coming. Ideally, there will be no *.mk file at all, just one Makefile in which the maintainer can include a maint.mk file that will only live on orgmode.org server (since we are releasing from there.) It would be easy enough to hide the *.mk files in some subdirectory (a new one or perhaps UTILITIES) to unclutter the main directory. I've split off the verious parts for now based on function, and yes, some of these may be re-integrated later. At the moment this is only there to make these different functions visible since calling make still reads them in all at once and acts as if they were a single file. But maybe you're already heading in this direction, or my suggestion goes against your goal. Let me elaborate: The original goal was that I would not need to change the Makefile when doing my local setup since I frequently change it for testing. Right now I'm rebasing a short branch with my local setup onto whatever branch I'm working on so I don't clutter the history with these changes. Splitting off an optional file local.mk is what achieves that goal most cleanly, IMHO. I can now just link to whatever setup I need at the moment in the testing branches or register a stable setup in other branches. The Makefile has indeed been shortened to the extreme based on the idea that it should fit onto a single screen when someone does a 'cat Makefile' and not contain anything that needs to be prefixed with an explanation. Ideally the Makefile would be clear enough to obsolete the necessity for an INSTALL file (which doesn't currently exist anyway). The default.mk has been introduced to be an easy template from which to create a local.mk by copying. This is not strictly necessary, but to me it looks easier than to tell people to copy the right part of the Makefile into local.mk. But both options will need to be accompanied by instructions and it's mainly a question of them being easy to follow. Come to think of it, I'll probably add a target that creates local.mk… so that issue likely becomes moot. The server part of the Makefile could actually be included from local.mk, so it would not need to exist in the standard distribution (at least not in the top level directory). The existence of both targets.mk and maint-targets.mk is transitory until things sort cleanly into one or the other category. User visible targets could then wander back into the Makefile, while the maintainer targets would become part of another optional include. The dependencies have been split off since ideally they would be auto-generated by make. PS: I've just completed the install of Emacs24 in parallel to the Emacs23.3, so I should can make sure that make will succeed with both. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Makefile restructuring
Branch is rebased onto current master. I'm now using a sub-make for ./lisp. Compiling and making the org-install.el in ./lisp rather than from toplevel also ensures that both the new (Emacs24) and old autoload.el produces the correct result. It is now possible to copy default.mk to local.mk and then alter the definitions in local.mk — make will automatically use the definitions in local.mk if it is present. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Makefile restructuring
Bastien b...@altern.org writes: Okay - I'll follow that branch till the change becomes mature. I've set up the feature branch Makefile in my org-mode clone on repo.or.cz. Assuming you already have orgmode.git cloned (it does not really matter where from), do a git remote add -t Makefile remote-tableheadings git://repo.or.cz/org-mode/org-tableheadings.git git fetch remote-tableheadings Makefile:local-Makefile git checkout local-Makefile to get it (change remote-tableheadings and local-Makefile to suit your naming conventions for remotes and local branches, respectively). I will be _rebasing_ against master during development, so expect history in this branch to be volatile. As always, testers and their comments are welcome. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
