Please test the new Makefile

Please test the new Makefile

[Bastien]

Dear all,

I've now bundled Achim's new Makefile in these archives:

  http://orgmode.org/Org-7.8.03-TestMakefile.tar.gz
  http://orgmode.org/Org-7.8.03-TestMakefile.zip

Can some of you test the make procedures from there?

Things are fine here, you should be safe.  The purpose of 
the test is to make sure `make && make install' do the right
thing in various setups.  

Thanks for your help,

Ps: for those who want to test this from Achim's branch, 
here is the recipe, assuming you are in your org-mode dir:

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

-- 
 Bastien

Re: Please test the new Makefile

[Takaaki ISHIKAWA]

Hi Bastien,

I have tried to install the new package in my clean VM of Suse 12.1.
I'd like to report my install experience.

> http://orgmode.org/Org-7.8.03-TestMakefile.zip

1. When I just type "make", I find a fatal error message:
  Not a git repository (or any parent up to mount parent )
  Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

2. "make all" works well with the same message above.
  "make all" will be the default command instead of "make"?

3. Packages are installed into "/usr/share/emacs/site-lisp".
  This is a known change in ML.

4. "M-x org-version" shows:
  ( @ /usr/share/emacs/site-lisp/org/org-install.el)

Best regards,
Takaaki Ishikawa

----
GNU Emacs 23.3.1 (x86_64-suse-linux-gnu, GTK+ Version 2.24.7) of 2011-10-30 on build17

Re: Please test the new Makefile

[Achim Gratz]

Am 22.12.2011 02:35, schrieb Takaaki ISHIKAWA:
> 1. When I just type "make", I find a fatal error message:
>    Not a git repository (or any parent up to mount parent )
>    Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

Just "make" doesn't work anymore (it displays a usage section to conform 
to GNU convention), you'll need "make all".  This now implies a "make 
clean", so you'll normally don't need this as an extra step anymore.

> 2. "make all" works well with the same message above.
>    "make all" will be the default command instead of "make"?

Yes.

> 3. Packages are installed into "/usr/share/emacs/site-lisp".
>    This is a known change in ML.

If you want it installed someplace else, create a file "local.mk" and 
override the variables in "default.mk".  So under Linux (assuming you're 
not logged in as root), you would do

make all && sudo make install

> 4. "M-x org-version" shows:
>    ( @ /usr/share/emacs/site-lisp/org/org-install.el)

I have not yet safeguarded against the situation where make is 
available, but not git.  You can also override this temporarily in 
targets.mk (GITVERSION, ORGVERSION and GITSTATUS).  I will re-arrange 
this to either test for a Git directory or make it overridable via 
"local.mk" (or both).

Thank you for testing!

-- 
Achim.

(on the road :-)

Re: Please test the new Makefile

[Takaaki ISHIKAWA]

Dear Achim,

Hi. Thank you for your comment and great work on refactoring Makefile.

> Just "make" doesn't work anymore (it displays a usage section to conform to GNU convention), you'll need "make all".  This now implies a "make clean", so you'll normally don't need this as an extra step anymore.

I see why you use "make all".

Could you tell me the current trend of Makefile?
I think "make" and "make all" have the same effect usually.
In the new Makefile of org-mode, however, "make" is used 
for displaying options of make command.
Is this familiar to all?

For example, GNU Emacs doesn't require "make all", just "make".

Best regards,
Takaaki Ishikawa

Re: Please test the new Makefile

[Bastien]

Hi Achim and Takaaki,

Takaaki ISHIKAWA <takaxp@ieee.org> writes:

> I think "make" and "make all" have the same effect usually.
> In the new Makefile of org-mode, however, "make" is used 
> for displaying options of make command.
> Is this familiar to all?
>
> For example, GNU Emacs doesn't require "make all", just "make".

If we can stick to "make" let's stick to it.

If it breaks GNU coding conventions, let's use "make all" instead, 
and send a bug report to emacs-devel...

Thanks,

-- 
 Bastien

Re: Please test the new Makefile

[ASSI]

[sorry if you get this twice
  - GMane seems to have trouble sending lately]

Am 22.12.2011 16:06, schrieb Takaaki ISHIKAWA:
> I think "make" and "make all" have the same effect usually.

Often they do, but GNU says that a simple "make" should behave like 
"make help".  I think this is appropriate for org mode since there is no 
INSTALL file that explains what to do and in most cases one would have 
to put some things in local.mk before running "make install".

> In the new Makefile of org-mode, however, "make" is used
> for displaying options of make command.
> Is this familiar to all?

I opted for this behaviour to align more closely to GNU convention and 
to avoid any surprising behaviour, but it is easy to make the default 
target "all" instead of "help".

> For example, GNU Emacs doesn't require "make all", just "make".

That's not exactly comparable since the Makefile for Emacs is the result 
of ./configure, so for Emacs make is just another tool used in a larger 
build system.


-- 
Achim.

(on the road :-)

Re: Please test the new Makefile

[Takaaki ISHIKAWA]

Hi. Achim,

Thank you for your kind explanations.
I learned a lot from you :)

> I opted for this behaviour to align more closely to GNU convention and to avoid any surprising behaviour, but it is easy to make the default target "all" instead of "help".

I think many Org users are familiar to the previous
installation procedure by "make" not "make all",
and some users wrote it in their blog, Org manual [*1] too.
Don't you think this change has a wide impact for them?
But it's just a concern to me :)

[*1] http://orgmode.org/manual/Installation.html

Re: Please test the new Makefile

[Achim Gratz]

Am 26.12.2011 05:58, schrieb Takaaki ISHIKAWA:
> I think many Org users are familiar to the previous installation
> procedure by "make" not "make all", and some users wrote it in their
> blog, Org manual [*1] too.

Yes, the manual would need to be changed in any case.  The semantics of 
some  targets have changed as well, even when they are having the same name.

> Don't you think this change has a wide impact for them? But it's just
> a concern to me :)

Again, if the consensus is that the default target should be "all", this
is just a single line to add at the top of the main Makefile:

.DEFAULT:	all

There are a few other changes I will have to implement, buit it will be
in the new year.

-- 
Achim.

(on the road :-)

Re: Please test the new Makefile

[Achim Gratz]

I've implemented a few improvements in my fork that should take care of
most issues raised in recent discussions:

- default target is now "all" instead of "help"

- make does not complain when not inside a Git tree

- all installations prefixed with $(DESTDIR) to allow for staged
  installation

- introduced $(datadir) as replacement for $(etcdir) and moved into
  default.mk; $(datadir) is recorded as a defconst into org-install.el

- more robust shell code

- removed maint.mk and maint-targets.mk, these will have to be rolled
  into local.mk (or included from there) on the server


I'm uncertain about the integration of the ODT exporter (although it
works on my machine): it seems that the schema files should reside in
etc/schema (and ETCDIR should include schema on install)?  Why are the
schema files only in contrib?  Also there is some compile-time
evaluation of org-odt-data-dir that seems unnecessary to me (I don't set
this variable at compile-time, anyhow)?



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

DIY Stuff:
http://Synth.Stromeko.net/DIY.html

Re: Please test the new Makefile

[Achim Gratz]

Rebased to 7.8.03.

Achim Gratz <Stromeko@nexgo.de> writes:
> I'm uncertain about the integration of the ODT exporter (although it
> works on my machine): it seems that the schema files should reside in
> etc/schema (and ETCDIR should include schema on install)? 

I went ahead and moved the schema dir from contrib to etc and adapted
the Makefile to install it.


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: Please test the new Makefile

[Achim Gratz]

Achim Gratz <Stromeko@nexgo.de> writes:
> I went ahead and moved the schema dir from contrib to etc and adapted
> the Makefile to install it.

Now pushed to my Makefile fork after testing it on Win7 (and rebased
again to current master).


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: Please test the new Makefile

[Achim Gratz]

Am 21.12.2011 19:47, schrieb Bastien:

> Things are fine here, you should be safe.  The purpose of
> the test is to make sure `make&&  make install' do the right
> thing in various setups.

Actually, that should be

make all && make install

or (under Unixoid system and running as a normal user):

make all && sudo make install

Before doing a "make install", please check "default.mk" for where it 
tries to put things.  You can override this by creating a file 
"local.mk" which just has definitions for those variables that you want 
to change (most of the time, just "prefix").

The installation is put into its own sub-directory "org" by default, if 
you've had a previous installation "flat" in site-lisp, you either need 
to remove those files or also install "flat" again - otherwise you will 
very likely pick up stale files from the previous installation.

If you are brave, there is a non-documented target "clean-install" that 
will remove those files, but you should make doubly sure that lispdir 
and infodir point at the right place (run "make -n clean-install" and 
check which files make would remove if you ran it without "-n").

> 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

It is currently easier to test this from Git, since the makefile 
actually assumes a Git directory to be able to get at the version 
strings.  If you get bitten by this, please change the following lines 
in default.mk:

GITVERSION	= $(shell git describe --abbrev=6 HEAD)
ORGVERSION	= $(subst release_,,$(shell git describe --abbrev=0 HEAD))
GITSTATUS	= $(shell git status -uno --porcelain)

to

GITVERSION	= "release_7.8.03-Makefile
ORGVERSION	= "7.8.03"
GITSTATUS	= ""

I'm currently not able to rebase the branch on repo.or.cz, but you can 
do this yourself if you have your own local branch and also mirror the 
normal orgmode.git:

git remote update
git rebase local-Makefile origin/master

(Hope I got this right, I'm currently not able to test it myself :-)


-- 
Achim.

(on the road :-)