[ww-users] 3134685: one-stop makefile for recursive operations

[lee w. <wor...@gm...>]

An open question about how to make "make" include the special WorkingWiki 
rules when appropriate and not when it isn't.  These are the rules for 
making .tex into .pdf and .xhtml, but also a bunch of useful rules for R 
programs that Jonathan created for use on the McMaster site.

Below is the discussion so far from the feature-requests tracker, 
including my very biased roundup.  Jonathan, I invite your response.

Lee

---------- Edited and forwarded ----------

Feature Requests item #3134685, was opened at 2010-12-10 16:33

Submitted By: Lee Worden (worden)
Assigned to: Lee Worden (worden)
Summary: one-stop makefile for recursive operations

Initial Comment:

Date: Fri, 10 Dec 2010 16:29:19 -0800 (PST)
From: lee worden <wor...@gm...>

Okay.  As I understand it, the unmet need is to be able to write a simple
recursive make line like

         $(MAKE) -C $(PROJECT_DIR_Somewhere) -f [SOMETHING SIMPLE] target

which will include all the same makefiles that would be included by a WW
operation in PROJECT_DIR_Somewhere.  That is, either the one file
{makefile,Makefile,GNUMakefile}, or that file plus the default makefiles,
site makefiles, and .mk files, depending on whether the Use default
makefiles option is enabled for that project.

Correct me if I'm wrong.

I propose to have WW create for each project a file called
$(PROJECT_DIR_Somewhere).makefile that will do that job.  That is, it will
not be in the directory but next to it.  This will meet the above needs,
plus the needs of hypothetical WW users who want to import a project and not
have WW add unexpected files to it.

I'll implement this by having two standard makefiles, one with the WW stuff
enabled and one without, and each of these project-specific makefiles will
be a link to one or the other of these.

How does that sound?
lw

----------------------------------------------------------------------

Comment By: Lee Worden (worden)
Date: 2010-12-24 12:08

Message:
from dushoff:

My first choice is that we make a directory by saying "make" in the
directory.  This seems transparent to me for calling, exporting, etc.
My current idea for implementation would be to _keep_ the checkbox ["Use
default rules" or whatever it's called - lw].
Iff "use rules" is on, WW would place a "makefile" in the directory at
source-sync.  Users who want to provide their own "makefile" but want
to use our rules, would need to invoke our -before and -after stuff
themselves; we would of course make this easy.

----------------------------------------------------------------------

Comment By: Lee Worden (worden)
Date: 2010-12-24 12:17

Message:
Thus we have two competing proposals:

1. mine: put a makefile outside the project directory.
Pros: You can import your existing project and it will work the same in WW
as outside.  This seems important to me:
- a. in the future when I picture us moving projects in and out of WW more
fluidly.
- b. when prospective users try out WW but putting their current project
in it.  If it messes with their working directory by hijacking the makefile
structure, they will be offended even if it's functionally unobtrusive.
Cons: When you create a project in WW and export it, in order to get the
same make behavior as inside you have to use "make -f <something>" rather
than plain make.  (You can make it a shell alias though, like "wwmake
target".)

2. JD's: put a "makefile" in the project directory that will unobtrusively
override and extend the behavior of any existing "Makefile".
Pros: "make" just works and includes the WW-specific rules.
Cons: see "Pros" for proposal 1.  Do we create "makefile" for projects
that have a "Makefile" but not for ones that have a "makefile"?  This
imposes an interpretation on the project author's intentions that I don't
think is warranted.  The idea that "Makefile" means you want our rules for
making .tex files into .pdf and .xhtml, while "makefile" means you want
those features disabled seems inaccurate and can cause great confusion and
frustration.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1527388&aid=3134685&group_id=366300