Re: [O] Makefile restructuring

[Achim Gratz]

Bastien <address@hidden> 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