From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: Makefile restructuring Date: Sat, 16 Jul 2011 16:56:52 +0200 Message-ID: <871uxqz32j.fsf@Rainer.invalid> References: <87k4bqwkyw.fsf@gnu.org> <87sjqejvob.fsf@Rainer.invalid> <87k4bqjnwu.fsf@Rainer.invalid> <87fwmdkind.fsf@Rainer.invalid> <874o2t81qu.fsf@gnu.org> <87liw43iys.fsf@Rainer.invalid> <8762n8d4ys.fsf@gnu.org> <87ei1u6u3q.fsf_-_@Rainer.invalid> <87pqlae8d7.fsf@altern.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([140.186.70.92]:40800) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qi6Iq-0004gb-H0 for emacs-orgmode@gnu.org; Sat, 16 Jul 2011 10:57:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qi6Io-0006ir-Dp for emacs-orgmode@gnu.org; Sat, 16 Jul 2011 10:57:12 -0400 Received: from lo.gmane.org ([80.91.229.12]:46917) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qi6In-0006iG-BV for emacs-orgmode@gnu.org; Sat, 16 Jul 2011 10:57:09 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Qi6Il-0003js-It for emacs-orgmode@gnu.org; Sat, 16 Jul 2011 16:57:07 +0200 Received: from p57aaa79a.dip.t-dialin.net ([87.170.167.154]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Jul 2011 16:57:07 +0200 Received: from Stromeko by p57aaa79a.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Jul 2011 16:57:07 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org 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 "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