From: Achim Gratz <Stromeko@nexgo.de>
To: emacs-orgmode@gnu.org
Subject: Re: Makefile restructuring
Date: Sat, 16 Jul 2011 16:56:52 +0200 [thread overview]
Message-ID: <871uxqz32j.fsf@Rainer.invalid> (raw)
In-Reply-To: 87pqlae8d7.fsf@altern.org
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
next prev parent reply other threads:[~2011-07-16 14:57 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-10 9:10 patch makefile solve a couple debian build problems and a slackware build problem Jude DaShiell
2011-07-10 9:20 ` Bastien
2011-07-10 10:07 ` Achim Gratz
2011-07-10 12:55 ` Achim Gratz
2011-07-10 20:03 ` Achim Gratz
2011-07-11 12:01 ` Bastien
2011-07-11 16:00 ` Achim Gratz
2011-07-11 18:53 ` Bastien
2011-07-13 16:08 ` Makefile restructuring Achim Gratz
2011-07-16 11:54 ` Bastien
2011-07-16 14:56 ` Achim Gratz [this message]
2011-07-16 21:17 ` Achim Gratz
2011-07-17 17:30 ` Achim Gratz
2011-12-16 9:59 ` Achim Gratz
2011-07-19 18:28 ` Achim Gratz
2011-10-28 10:00 ` Achim Gratz
2011-10-29 11:22 ` Michael Brand
2011-10-30 7:33 ` Achim Gratz
2011-10-30 14:20 ` Michael Brand
2011-11-06 19:06 ` Achim Gratz
2011-11-06 19:18 ` Jambunathan K
2011-11-06 19:38 ` Achim Gratz
2011-11-06 20:25 ` Jambunathan K
2011-11-08 21:35 ` Achim Gratz
2011-11-13 12:47 ` Achim Gratz
2011-11-08 18:00 ` Achim Gratz
2011-11-08 21:23 ` Achim Gratz
2012-04-21 10:39 ` Bastien
2012-04-21 11:40 ` suvayu ali
2012-04-21 13:08 ` Samuel Wales
2012-04-21 13:26 ` Achim Gratz
2012-04-21 13:49 ` Samuel Wales
2012-04-21 14:34 ` Achim Gratz
2012-04-21 15:41 ` Samuel Wales
2012-04-21 15:44 ` Achim Gratz
2012-04-22 15:22 ` suvayu ali
2012-04-22 15:34 ` Achim Gratz
2012-04-23 7:32 ` suvayu ali
2012-04-24 1:46 ` Mike McLean
2012-04-24 4:55 ` Achim Gratz
2012-04-21 15:29 ` Achim Gratz
2012-04-21 15:43 ` Bastien
2012-04-21 18:50 ` Samuel Wales
2012-04-21 18:55 ` Achim Gratz
2012-04-21 19:12 ` Samuel Wales
2012-04-21 19:17 ` Achim Gratz
2012-04-21 20:47 ` Samuel Wales
2012-04-22 6:34 ` Achim Gratz
2012-04-22 15:31 ` Samuel Wales
2012-04-22 15:42 ` Achim Gratz
2012-04-21 13:37 ` Jambunathan K
2012-04-21 14:25 ` François Allisson
2012-04-21 17:57 ` Martyn Jago
2012-04-21 18:30 ` Achim Gratz
2012-04-21 20:45 ` François Allisson
2012-04-21 20:57 ` Samuel Wales
2012-04-21 23:27 ` Martyn Jago
2012-04-23 5:05 ` Achim Gratz
2012-04-25 18:00 ` Achim Gratz
2012-04-26 6:55 ` Bastien
2011-07-11 11:58 ` patch makefile solve a couple debian build problems and a slackware build problem Bastien
2011-07-11 15:39 ` Achim Gratz
2011-07-11 18:52 ` Bastien
2011-07-10 12:21 ` Nick Dokos
2011-07-10 12:49 ` Achim Gratz
2011-07-10 14:02 ` Jude DaShiell
2011-07-11 20:01 ` [PATCH] was: " Achim Gratz
2011-07-11 21:40 ` Nick Dokos
2011-07-11 22:19 ` Bastien
2011-07-13 15:45 ` Achim Gratz
2011-07-14 15:51 ` Bastien
2011-07-11 22:19 ` Bastien
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871uxqz32j.fsf@Rainer.invalid \
--to=stromeko@nexgo.de \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.