Re: patch makefile solve a couple debian build problems and a slackware build problem

Re: patch makefile solve a couple debian build problems and a slackware build problem

[Jude DaShiell]

The latest patch by Achim Gratz works for this problem for make 
install-info on debian squeeze.  The warning about using ginstall-info 
comes up, but the documentation updates from 7.5 to 7.6 none the less.

Re: patch makefile solve a couple debian build problems and a slackware build problem

[Bastien]

Hi Jude,

Jude DaShiell <jdashiel@shellworld.net> writes:

> The latest patch by Achim Gratz works for this problem for make 
> install-info on debian squeeze.  The warning about using ginstall-info 
> comes up, but the documentation updates from 7.5 to 7.6 none the less.

Thanks for confirming.

Achim and Nick, can I safely apply your patch or was it still a beta
version?

Thanks,

-- 
 Bastien

Re: patch makefile solve a couple debian build problems and a slackware build problem

[Achim Gratz]

Bastien <bzg@altern.org> writes:
> Achim and Nick, can I safely apply your patch or was it still a beta
> version?

My patch obsolotes what Nick was trying to achieve, but I'm just looking
at some other stuff in the Makefile that looks like it needs a makeover,
so I'd suggest we discuss this first and I'll submit a proper patch that
goes into patchwork. Here it goes:

It looks like the two targets relase and fixrelease have not actually
been used and at least fixrelease would not do what the comment is
trying to imply it should be doing.  If nobody uses them, these two
targets should probably be removed.

Then there's all the stuff that "makes sense only on the orgmode server,
do not run on your computer": if so, would it not be preferrable to fail
these targets when not run on the orgmode server, either by checking an
environment variable or a file that only exists on the server?

Is there any reason why the phony targets are not declared to be phony?
Even if GNU make is not used that should be compatible.


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: patch makefile solve a couple debian build problems and a slackware build problem

[Achim Gratz]

Achim Gratz <Stromeko@nexgo.de> writes:
[...]

I just realize that the Makefile already uses several GNU make
extensions.  If it's OK to use them (specifically include files and
conditional variable assignment), that would help to restructure the
Makefile so that it can be customized and maintained more easily.  Let
me know if I should work on a proposal in that direction or not.


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: patch makefile solve a couple debian build problems and a slackware build problem

[Achim Gratz]

Achim Gratz <Stromeko@nexgo.de> writes:
> I just realize that the Makefile already uses several GNU make
> extensions.  If it's OK to use them (specifically include files and
> conditional variable assignment), that would help to restructure the
> Makefile so that it can be customized and maintained more easily.  Let
> me know if I should work on a proposal in that direction or not.

I went ahead with splitting the Makefile up, it now looks like this:

--8<---------------cut here---------------start------------->8---
#
# Master Makefile for the org-mode distribution
#
include  default.mk
-include local.mk

.DEFAULT_GOAL := help
# Describe valid make targets for org-mode.
targets help:
	@echo
	@echo "Check the settings in default.mk first. If you need to adjust them, please"
	@echo "copy default.mk to local.mk and then make your edits in local.mk."
	@echo
	@echo "Usage:"
	@echo
	@echo "make              # compile Org ELisp files"
	@echo "make clean        # clean Elisp and documentation files"
	@echo "make all          # compile Org ELisp files and documentation"
	@echo
	@echo "make doc          # make all documentation"
	@echo "make info         # make Info documentation"
	@echo "make html         # make HTML documentation"
	@echo "make pdf          # make pdf documentation"
	@echo "make card         # make refcards documentation"
	@echo
	@echo "make install      # install Org"
	@echo "make install-lisp # install Org ELisp files"
	@echo "make install-info # install Org Info file"
	@echo

include  maint.mk
include  standard.mk
include  deps.mk
-include server.mk
--8<---------------cut here---------------end--------------->8---

Calling make without a target or with a target of "help" or "targets"
will give a short overview on how to set things up and use it.

Customization is done by creating a local.mk file that overrides the
settings in default.mk.  By doing this in your local branch, you never
need to worry that some change in the main repository will overwrite
your customizations and developing on a local branch with merging should
become easier (that was my main reason to always rebase my local
branch).  Merging back into the main branch requires some care, so the
repository should probably be configured to never allow a push that has
local.mk in it.

The same thing is done for the orgmode server.mk part so that it is not
distributed with the standard orgmode repository anymore.  For
illustration I've also separated the dependencies into deps.mk so that
they may be auto-generated (in which case they'd be removed from the
repository and get their own target).  I'll probably merge maint.mk and
standard.mk again, but for now they're separated.



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: patch makefile solve a couple debian build problems and a slackware build problem

[Bastien]

Hi Achim,

> I went ahead with splitting the Makefile up, it now looks like this:

this looks like a flexible solution we might use.

When you have time, please provide a patch to this effect.

Thanks for you work!

-- 
 Bastien

Re: patch makefile solve a couple debian build problems and a slackware build problem

[Achim Gratz]

Bastien <bzg@altern.org> writes:
> this looks like a flexible solution we might use.

Good.

> When you have time, please provide a patch to this effect.

I'll be on it, I should have something to show maybe next weekend.
Instead of posting a series of patches to the list, I'll add a feature
branch to my orgmode clone on repo.or.cz — I think that should be easier
to follow since I expect there will be a few versions back-and-forth
before things settle.

> Thanks for you work!

You're welcome.


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: patch makefile solve a couple debian build problems and a slackware build problem

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> I'll be on it, I should have something to show maybe next weekend.
> Instead of posting a series of patches to the list, I'll add a feature
> branch to my orgmode clone on repo.or.cz — I think that should be easier
> to follow since I expect there will be a few versions back-and-forth
> before things settle.

Okay - I'll follow that branch till the change becomes mature.

Thanks,

-- 
 Bastien

Re: Makefile restructuring

[Achim Gratz]

Bastien <bzg@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

Re: Makefile restructuring

[Bastien]

Hi Achim,

Achim Gratz <Stromeko@nexgo.de> writes:

> Bastien <bzg@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: Makefile restructuring

[Achim Gratz]

Bastien <bzg@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: Makefile restructuring

[Achim Gratz]

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: Makefile restructuring

[Achim Gratz]

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: Makefile restructuring

[Achim Gratz]

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: Makefile restructuring

[Achim Gratz]

Achim Gratz <Stromeko@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: Makefile restructuring

[Achim Gratz]

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: Makefile restructuring

[Michael Brand]

Hi Achim

On Fri, Oct 28, 2011 at 12:00, Achim Gratz <Stromeko@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: Makefile restructuring

[Achim Gratz]

Michael Brand <michael.ch.brand@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: Makefile restructuring

[Michael Brand]

Hi Achim

On Sun, Oct 30, 2011 at 08:33, Achim Gratz <Stromeko@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: Makefile restructuring

[Achim Gratz]

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: Makefile restructuring

[Jambunathan K]

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: Makefile restructuring

[Achim Gratz]

Jambunathan K <kjambunathan@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: Makefile restructuring

[Jambunathan K]

Achim Gratz <Stromeko@nexgo.de> writes:

> Jambunathan K <kjambunathan@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: Makefile restructuring

[Achim Gratz]

Jambunathan K <kjambunathan@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: Makefile restructuring

[Achim Gratz]

Achim Gratz <Stromeko@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: Makefile restructuring

[Achim Gratz]

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: Makefile restructuring

[Achim Gratz]

Achim Gratz <Stromeko@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: Makefile restructuring

[Bastien]

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: Makefile restructuring

[suvayu ali]

Hi,

On Sat, Apr 21, 2012 at 12:39, Bastien <bzg@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: Makefile restructuring

[Samuel Wales]

On 2012-04-21, Bastien <bzg@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: Makefile restructuring

[Achim Gratz]

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: Makefile restructuring

[Samuel Wales]

Hi Achim,

On 2012-04-21, Achim Gratz <Stromeko@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: Makefile restructuring

[Achim Gratz]

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: Makefile restructuring

[Samuel Wales]

On 2012-04-21, Achim Gratz <Stromeko@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: Makefile restructuring

[Achim Gratz]

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: Makefile restructuring

[suvayu ali]

Hi Achim,

Last time when I tested the latest changes, I overlooked something.

On Sat, Apr 21, 2012 at 16:34, Achim Gratz <Stromeko@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: Makefile restructuring

[Achim Gratz]

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: Makefile restructuring

[suvayu ali]

Hi Achim,

On Sun, Apr 22, 2012 at 17:34, Achim Gratz <Stromeko@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: Makefile restructuring

[Mike McLean]

On Apr 22, 2012, at 11:34 AM, Achim Gratz 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 auto loads".

This makes sense, and I’ve asked the question on how best to handle for el-get on Gihub. Meanwhile my original pull request has been merged, so for the moment at least el-get uses the ("compile" "autoloads" "info") workflow. You are correct that adding a make autoloads does work, I've used (and updated) compiled org-mode straight from the work tree for a few days now. If there is a better or more canonical way to do this, I'd be happy to change and work the changes back into el-get where I can.

> 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.

What do you do to make that work? It sounds like an intriguing possibility.

Re: Makefile restructuring

[Achim Gratz]

Mike McLean writes:
>> You can now easily keep multiple installations within the org directory
>> if so desired (I do this myself for testing).
>
> What do you do to make that work? It sounds like an intriguing possibility.

In a nutshell, I create multiple install directories (one for each
version of Emacs and Org) via the use of a separate local.mk file for
each install and set up the load-path in Emacs to select which one to
use.


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Makefile restructuring

[Achim Gratz]

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: Makefile restructuring

[Bastien]

Achim Gratz <Stromeko@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: Makefile restructuring

[Samuel Wales]

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: Makefile restructuring

[Achim Gratz]

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: Makefile restructuring

[Samuel Wales]

On 2012-04-21, Achim Gratz <Stromeko@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: Makefile restructuring

[Achim Gratz]

Samuel Wales writes:
> On 2012-04-21, Achim Gratz <Stromeko@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: Makefile restructuring

[Samuel Wales]

On 2012-04-21, Achim Gratz <Stromeko@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: Makefile restructuring

[Achim Gratz]

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: Makefile restructuring

[Samuel Wales]

On 2012-04-21, Achim Gratz <Stromeko@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: Makefile restructuring

[Achim Gratz]

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: Makefile restructuring

[Jambunathan K]

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: Makefile restructuring

[François Allisson]

> 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: Makefile restructuring

[Martyn Jago]

Hi Achim

François Allisson <francois@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: Makefile restructuring

[Achim Gratz]

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: Makefile restructuring

[François Allisson]

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: Makefile restructuring

[Samuel Wales]

On 2012-04-21, François Allisson <francois@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: Makefile restructuring

[Martyn Jago]

Achim Gratz <Stromeko@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: Makefile restructuring

[Achim Gratz]

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: Makefile restructuring

[Achim Gratz]

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

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:

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Improve compatibility with old Makefile --]
[-- Type: text/x-patch, Size: 3753 bytes --]

From f9f0c7b4e367259bafac1cb5cbec17dd2cff625a Mon Sep 17 00:00:00 2001
From: Achim Gratz <Stromeko@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 targets. =)
+	$(info = Created a default local.mk template.               =)
+	$(info = Setting "oldorg" as the default target.            =)
+	$(info = Please adapt local.mk to your local setup!         =)
+	$(info ======================================================)
 	-@$(SED) -n \
+		-e '1 i ## Remove the following line to make "all" the default target' \
+		-e '1 i oldorg:' \
 		-e '/-8<-/,/->8-/ {s/^\(\s*[^#]\)/#\1/;p}' \
 		-e '$$ i ## See default.mk for further configuration options.' \
 		default.mk > $@
-- 
1.7.9.2


[-- Attachment #3: Type: text/plain, Size: 197 bytes --]



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: Makefile restructuring

[Bastien]

Hi Achim,

Achim Gratz <Stromeko@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: patch makefile solve a couple debian build problems and a slackware build problem

[Bastien]

Hi Achim,

Achim Gratz <Stromeko@nexgo.de> writes:

> It looks like the two targets relase and fixrelease have not actually
> been used and at least fixrelease would not do what the comment is
> trying to imply it should be doing.  If nobody uses them, these two
> targets should probably be removed.

The targets release and fixrelease are for Org's maintainers.

> Then there's all the stuff that "makes sense only on the orgmode server,
> do not run on your computer": if so, would it not be preferrable to fail
> these targets when not run on the orgmode server, either by checking an
> environment variable or a file that only exists on the server?

Yes -- maybe with a warning like: "These target is meant for using by
the maintainers".

The other solution would be to simply remove these target and to use 
a local Makefile on the server.  It's more clean from the user's point 
of view, and just some little extra work for the maintainers.

What would you suggest?

> Is there any reason why the phony targets are not declared to be
> phony?

"phony"?

>
>
> Regards,
> Achim.

-- 
 Bastien

Re: patch makefile solve a couple debian build problems and a slackware build problem

[Achim Gratz]

Bastien <bzg@altern.org> writes:
> The targets release and fixrelease are for Org's maintainers.

Yes, but if they've been used, no trace is to be found in the repository
and in any case, what fixrelease is supposed to be doing is not what it
actually does — it's currently an exact copy of release. I'll sort it
out and make a proposal…

> The other solution would be to simply remove these target and to use 
> a local Makefile on the server.  It's more clean from the user's point 
> of view, and just some little extra work for the maintainers.
>
> What would you suggest?

As detailed in my other posting I'd remove them from the Makefile that
is distributed and the server would have an extra file with those
targets that are useful only there.  Gory details to follow.

>> Is there any reason why the phony targets are not declared to be
>> phony?
>
> "phony"?

A target whose recipe doesn't produce a file with the same name is
called "phony" in make-speech; I used to call them decoys.  The problem
with that age-old make idiom is when someone inadvertently creates a
file with that name — say, "test" — and "make test" suddenly doesn't
work anymore, so most makes allow you to declare them to avoid that
particular trap.


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: patch makefile solve a couple debian build problems and a slackware build problem

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> Yes, but if they've been used, no trace is to be found in the repository
> and in any case, what fixrelease is supposed to be doing is not what it
> actually does — it's currently an exact copy of release. I'll sort it
> out and make a proposal…

Would be nice, thanks.

I never had to use fixrelease so far, no surprise I didn't notice this.

> As detailed in my other posting I'd remove them from the Makefile that
> is distributed and the server would have an extra file with those
> targets that are useful only there.  Gory details to follow.

Okay - thanks!

> A target whose recipe doesn't produce a file with the same name is
> called "phony" in make-speech; I used to call them decoys.  The problem
> with that age-old make idiom is when someone inadvertently creates a
> file with that name — say, "test" — and "make test" suddenly doesn't
> work anymore, so most makes allow you to declare them to avoid that
> particular trap.

I learned something -- thanks for the explanations!

-- 
 Bastien

Re: patch makefile solve a couple debian build problems and a slackware build problem

[Nick Dokos]

Bastien <bzg@altern.org> wrote:

> Hi Jude,
> 
> Jude DaShiell <jdashiel@shellworld.net> writes:
> 
> > The latest patch by Achim Gratz works for this problem for make 
> > install-info on debian squeeze.  The warning about using ginstall-info 
> > comes up, but the documentation updates from 7.5 to 7.6 none the less.
> 
> Thanks for confirming.
> 
> Achim and Nick, can I safely apply your patch or was it still a beta
> version?
> 

Achim's patch is different from mine (which might very well be wrong: I
was trying to divine what is happening without access to a system that
runs Debian or Slackware). I applied Achim's patch and it works on my
Ubuntu system (I get the same warning that this is GNU install-info, not
dpkg install-info that Jude gets, which is fine - if that's all that's
different, then we can document that).

However, I don't understand how changing the command affects other
systems: in particular OS X and/or Windows (as well as other Linux
distros and other Unixes), so I will plead "nolo contendere" here, but I
wouldn't apply it until people on those systems test it and report
success.

My worry is this: before Achim's patch, the "other" systems run the
following command:

	$(INSTALL_INFO) --info-file=$(INFOFILES) --info-dir=$(infodir)

I presume without trouble. After his patch, they run

	$(INSTALL_INFO) --infodir=$(infodir) $(INFOFILES)

Does the install-info on other systems really grok the --infodir option?
Isn't it just straight GNU install-info? What am I missing?

Nick

Re: patch makefile solve a couple debian build problems and a slackware build problem

[Achim Gratz]

Nick Dokos <nicholas.dokos@hp.com> writes:
> My worry is this: before Achim's patch, the "other" systems run the
> following command:
>
> 	$(INSTALL_INFO) --info-file=$(INFOFILES) --info-dir=$(infodir)

The invocation with --info-files is only understood by GNU install-info,
that was presumably the reason for introducing the extra target
install-info-debian.

> I presume without trouble. After his patch, they run
>
> 	$(INSTALL_INFO) --infodir=$(infodir) $(INFOFILES)

This invocation does the same thing (per the man and info manuals) on
GNU install-info, but is also compatible with the older install-info
supplied by Debian, which does not know about some options of GNU info.
So whichever install-info gets chosen (since we cannot know what $PATH
is set to) should work.  If it is GNU install-info, then the warning
message is printed that we actually called a wrapper script that hands
off its arguments to ginstall-info.  If it is the dpkg install-info,
then we get a bunch of verbose output that GNU install-info doesn't
produce, but it also results in a working info page.

> Does the install-info on other systems really grok the --infodir option?
> Isn't it just straight GNU install-info? What am I missing?

On Windows you can either have MSys or Cygwin to get install-info.  Both
really are GNU install-info, so unless there is yet another install-info
I don't see why this would not work.


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: patch makefile solve a couple debian build problems and a slackware build problem

[Jude DaShiell]

I'm on my slackware system right now.  Here's the contents of /etc/issue 
and I left this as the out of the box default:
Welcome to \s \r (\l)

I had to do git close with the line in the installation notes to get 
org-mode to update.  The git program refused to overwrite the original 
Makefile.  So having done that I ran make all sudo make install sudo 
make install-info and there were no errors or warnings of any kind.  
info org tells me org documentation is at 7.6 now too.

On Sun, 10 Jul 2011, Achim Gratz wrote:

> Nick Dokos <nicholas.dokos@hp.com> writes:
> > My worry is this: before Achim's patch, the "other" systems run the
> > following command:
> >
> > 	$(INSTALL_INFO) --info-file=$(INFOFILES) --info-dir=$(infodir)
> 
> The invocation with --info-files is only understood by GNU install-info,
> that was presumably the reason for introducing the extra target
> install-info-debian.
> 
> > I presume without trouble. After his patch, they run
> >
> > 	$(INSTALL_INFO) --infodir=$(infodir) $(INFOFILES)
> 
> This invocation does the same thing (per the man and info manuals) on
> GNU install-info, but is also compatible with the older install-info
> supplied by Debian, which does not know about some options of GNU info.
> So whichever install-info gets chosen (since we cannot know what $PATH
> is set to) should work.  If it is GNU install-info, then the warning
> message is printed that we actually called a wrapper script that hands
> off its arguments to ginstall-info.  If it is the dpkg install-info,
> then we get a bunch of verbose output that GNU install-info doesn't
> produce, but it also results in a working info page.
> 
> > Does the install-info on other systems really grok the --infodir option?
> > Isn't it just straight GNU install-info? What am I missing?
> 
> On Windows you can either have MSys or Cygwin to get install-info.  Both
> really are GNU install-info, so unless there is yet another install-info
> I don't see why this would not work.
> 
> 
> Regards,
> Achim.
> 

Re: [PATCH] was: patch makefile solve a couple debian build problems and a slackware build problem

[Achim Gratz]

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

Bastien <bzg@altern.org> writes:
> Achim and Nick, can I safely apply your patch or was it still a beta
> version?

I've reworked my patch to include a changelog and correct documentation.
Additionally I've now tested it on Windows, both with Cygwin and Msys.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-remove-Makefile-target-install-info-debian-modify-in.patch --]
[-- Type: text/x-patch, Size: 3148 bytes --]

From 11a243c4c01f5c2802328e3e4f7956abbaafd7e8 Mon Sep 17 00:00:00 2001
From: Achim Gratz <Stromeko@Stromeko.DE>
Date: Sun, 10 Jul 2011 08:42:20 +0200
Subject: [PATCH] remove Makefile target install-info-debian, modify
 install-info to be compatible

* Makefile: remove target install-info-debian and modify target
  install-info so that it is compatible with the older dpkg version
  of install-info that resides in /usr/sbin and may be picked up
  when root is installing info files

Initial reporting by Jude DaShiell, suggestions for changing Makefile
by Nick Dokos.  The solution implemented re-arranges the arguments to
install-info to be compatible with both the dpkg and GNU version of
the program.  On Debian, /usr/bin/install-info is actually a wrapper
that calls /usr/bin/ginstall-info and issues the following warning
when called as root:

This is not dpkg install-info anymore, but GNU install-info
See the man page for ginstall-info for command line arguments

This warning can be safely ignored since we actually prefer that GNU
install-info is called even though we've arranged the arguments to
be compatible with dpkg install-info.

Tested on openSuSE Tumbleweed, Win7/Pro (both MSys and Cygwin) and by
Jude DaShiell on Debian Squeeze and Slackware.

TINYCHANGE
---
 Makefile     |    3 ---
 doc/org.texi |   18 ++++++++++++------
 2 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/Makefile b/Makefile
index fe833d7..eb2597f 100644
--- a/Makefile
+++ b/Makefile
@@ -222,9 +222,6 @@ install-lisp: $(LISPFILES) $(ELCFILES)
 install-info: $(INFOFILES)
 	if [ ! -d $(infodir) ]; then $(MKDIR) $(infodir); else true; fi ;
 	$(CP) $(INFOFILES) $(infodir)
-	$(INSTALL_INFO) --info-file=$(INFOFILES) --info-dir=$(infodir)
-
-install-info-debian: $(INFOFILES)
 	$(INSTALL_INFO) --infodir=$(infodir) $(INFOFILES)
 
 autoloads: lisp/org-install.el
diff --git a/doc/org.texi b/doc/org.texi
index 7f92382..c8ff8a0 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -880,15 +880,21 @@ make install
 @end example
 
 Installing Info files is system dependent, because of differences in the
-@file{install-info} program.  In Debian it copies the info files into the
-correct directory and modifies the info directory file.  In many other
-systems, the files need to be copied to the correct directory separately, and
-@file{install-info} then only modifies the directory file.  Check your system
-documentation to find out which of the following commands you need:
+@file{install-info} program.  The following should correctly install the Info
+files on most systems, please send a bug report if not@footnote{The output
+from install-info (if any) is also system dependent.  In particular Debian
+and it's derivatives use two different versions of install-info and you may
+see the message:
+
+@example
+This is not dpkg install-info anymore, but GNU install-info
+See the man page for ginstall-info for command line arguments
+@end example
+
+@noindent which can be safely ignored.}.
 
 @example
 make install-info
-make install-info-debian
 @end example
 
 Then add the following line to @file{.emacs}.  It is needed so that
-- 
1.7.6


[-- Attachment #3: Type: text/plain, Size: 184 bytes --]




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: [PATCH] was: patch makefile solve a couple debian build problems and a slackware build problem

[Nick Dokos]

Achim Gratz <Stromeko@nexgo.de> wrote:

> From 11a243c4c01f5c2802328e3e4f7956abbaafd7e8 Mon Sep 17 00:00:00 2001
> From: Achim Gratz <Stromeko@Stromeko.DE>
> Date: Sun, 10 Jul 2011 08:42:20 +0200
> Subject: [PATCH] remove Makefile target install-info-debian, modify
>  install-info to be compatible
> 
> * Makefile: remove target install-info-debian and modify target
>   install-info so that it is compatible with the older dpkg version
>   of install-info that resides in /usr/sbin and may be picked up
>   when root is installing info files
> 
> Initial reporting by Jude DaShiell, suggestions for changing Makefile
> by Nick Dokos.  The solution implemented re-arranges the arguments to
> install-info to be compatible with both the dpkg and GNU version of
> the program.  On Debian, /usr/bin/install-info is actually a wrapper
> that calls /usr/bin/ginstall-info and issues the following warning
> when called as root:
> 
> This is not dpkg install-info anymore, but GNU install-info
> See the man page for ginstall-info for command line arguments
> 
> This warning can be safely ignored since we actually prefer that GNU
> install-info is called even though we've arranged the arguments to
> be compatible with dpkg install-info.
> 
> Tested on openSuSE Tumbleweed, Win7/Pro (both MSys and Cygwin) and by
> Jude DaShiell on Debian Squeeze and Slackware.
> 
> TINYCHANGE
> ---
>  Makefile     |    3 ---
>  doc/org.texi |   18 ++++++++++++------
>  2 files changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index fe833d7..eb2597f 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -222,9 +222,6 @@ install-lisp: $(LISPFILES) $(ELCFILES)
>  install-info: $(INFOFILES)
>  	if [ ! -d $(infodir) ]; then $(MKDIR) $(infodir); else true; fi ;
>  	$(CP) $(INFOFILES) $(infodir)
> -	$(INSTALL_INFO) --info-file=$(INFOFILES) --info-dir=$(infodir)
> -
> -install-info-debian: $(INFOFILES)
>  	$(INSTALL_INFO) --infodir=$(infodir) $(INFOFILES)
>  
>  autoloads: lisp/org-install.el
> diff --git a/doc/org.texi b/doc/org.texi
> index 7f92382..c8ff8a0 100644
> --- a/doc/org.texi
> +++ b/doc/org.texi
> @@ -880,15 +880,21 @@ make install
>  @end example
>  
>  Installing Info files is system dependent, because of differences in the
> -@file{install-info} program.  In Debian it copies the info files into the
> -correct directory and modifies the info directory file.  In many other
> -systems, the files need to be copied to the correct directory separately, and
> -@file{install-info} then only modifies the directory file.  Check your system
> -documentation to find out which of the following commands you need:
> +@file{install-info} program.  The following should correctly install the Info
> +files on most systems, please send a bug report if not@footnote{The output
> +from install-info (if any) is also system dependent.  In particular Debian
> +and it's derivatives use two different versions of install-info and you may
       ^^^^
       its

> +see the message:
> +
> +@example
> +This is not dpkg install-info anymore, but GNU install-info
> +See the man page for ginstall-info for command line arguments
> +@end example
> +
> +@noindent which can be safely ignored.}.
>  
>  @example
>  make install-info
> -make install-info-debian
>  @end example
>  
>  Then add the following line to @file{.emacs}.  It is needed so that
> -- 
> 1.7.6

Looks good to me - tested on Ubuntu 10.10.

Thanks,
Nick

Re: [PATCH] was: patch makefile solve a couple debian build problems and a slackware build problem

[Bastien]

Nick Dokos <nicholas.dokos@hp.com> writes:

>> +and it's derivatives use two different versions of install-info and you may
>        ^^^^
>        its

Fixed, thanks!

-- 
 Bastien

Re: [PATCH] was: patch makefile solve a couple debian build problems and a slackware build problem

[Achim Gratz]

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

Nick Dokos <nicholas.dokos@hp.com> writes:
>> +and it's derivatives use two different versions of install-info and you may
>        ^^^^
>        its

Thanks for catching that.

My patch also did not remove the documentation of the removed target in
the help/targets section of the Makefile.  I'm attaching a patch to
correct that.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-remove-documentation-for-removed-make-target-install.patch --]
[-- Type: text/x-patch, Size: 817 bytes --]

From 5372528a02d29ef92487d2a9cf46663804f8c9e2 Mon Sep 17 00:00:00 2001
From: Achim Gratz <Stromeko@Stromeko.DE>
Date: Wed, 13 Jul 2011 17:26:45 +0200
Subject: [PATCH] remove documentation for removed make target
 install-info-debian

* Makefile: also remove the documentation explaining the use of target
  install-info-debian, which was removed previously

TINYCHANGE
---
 Makefile |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index eb2597f..10093ed 100644
--- a/Makefile
+++ b/Makefile
@@ -527,4 +527,3 @@ targets help:
 	@echo "make install - install Org"
 	@echo "make install-lisp - install Org ELisp files"
 	@echo "make install-info - install Org Info file"
-	@echo "make install-info-debian - install info on old debian systems (newer use ginstall)"
-- 
1.7.6


[-- Attachment #3: Type: text/plain, Size: 190 bytes --]



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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [PATCH] was: patch makefile solve a couple debian build problems and a slackware build problem

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> My patch also did not remove the documentation of the removed target in
> the help/targets section of the Makefile.  I'm attaching a patch to
> correct that.

Applied, thanks!

-- 
 Bastien

Re: [PATCH] was: patch makefile solve a couple debian build problems and a slackware build problem

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> Bastien <bzg@altern.org> writes:
>> Achim and Nick, can I safely apply your patch or was it still a beta
>> version?
>
> I've reworked my patch to include a changelog and correct documentation.
> Additionally I've now tested it on Windows, both with Cygwin and Msys.

Great, thanks!

I just applied this patch.

-- 
 Bastien