Hi Achim,
Achim Gratz 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
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 o
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
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
>>
Hi Achim,
On Sun, Apr 22, 2012 at 17:34, 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 requ
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
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 alre
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?
Thi
On 2012-04-21, Achim Gratz 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
Hi Achim,
Last time when I tested the latest changes, I overlooked something.
On Sat, Apr 21, 2012 at 16:34, Achim Gratz 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", le
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
Achim Gratz 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 remo
On 2012-04-21, François Allisson 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 adv
On 2012-04-21, Achim Gratz 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 othe
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!
>
> Act
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 bran
Samuel Wales writes:
> On 2012-04-21, Achim Gratz 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 y
On 2012-04-21, Achim Gratz 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 w
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#BlofeldUserWav
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://thekafkap
Hi Achim
François Allisson 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
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]
Achim Gratz 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
On 2012-04-21, Achim Gratz 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 mak
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
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 beca
> 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.
Hi Achim,
On 2012-04-21, Achim Gratz 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 pro
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
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
On 2012-04-21, Bastien 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
Hi,
On Sat, Apr 21, 2012 at 12:39, Bastien 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 mod
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
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
Achim Gratz 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-direct
Jambunathan K 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 Makef
Achim Gratz 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
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-tablehea
Achim Gratz writes:
> Jambunathan K 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
>> functio
Jambunathan K 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 shoul
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
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
Hi Achim
On Sun, Oct 30, 2011 at 08:33, Achim Gratz 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
Michael Brand 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
Hi Achim
On Fri, Oct 28, 2011 at 12:00, Achim Gratz 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 br
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. Whi
Achim Gratz 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 conven
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
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
Bastien 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 "f
Hi Achim,
Achim Gratz writes:
> Bastien 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
>
>
Bastien 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-tableheading
52 matches
Mail list logo
