[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Getting rid of the makefles [was Re: devel/index]



On Wed, 8 Mar 2000, James A. Treacy wrote:

> On Tue, Mar 07, 2000 at 08:02:52PM +0100, peter karlsson wrote:
> > 
> > And in addition to changing to the above, all the Makefiles need to be
> > rewritten, so that the translations all depend on the originals.
> > 
> You may want to consider implementing this some other way since we
> may be getting rid of the Makefiles.
> 
> The issues are:
> CONS
> - they are more flexible
> - wmk is slower than make. make will quickly ignore all files that
>   don't need to be built. wmk stalls for a bit on every file. It may be
>   possible to avoid this by building a dependency file ahead of time,
>   but I haven't looked into it.

This is indeed feasible, WMk could produce a fragment of Makefile
containing dependencies.  But WMk does not know how to read it, so you
have to run make.
Note that i have never had any feedback on those dependency issues, so
this is still experimental.

Another (major) drawback of WMk is that the -A and -F flags only apply
to files, not dirs. There is actually no way to skip scanning a subdir.

[...]
> Additionally, we'd need to decide where the files are built (no 'make
> install' to install them elsewhere). The possibilities are:
> - move all translations into one directory. The html gets left in that
>   directory.
>   This gets ugly quickly: 10 files times 15 translations times 2 (.wml and
>   .<lang>.html) is 300 files. This would also require that the mirrors ignore
>   .wml files (not a big deal).
> - Force the html files to be created in another directory (the
>   equivalent of doing 'make install' in the current system). I'm not
>   sure how to implement this in wml. When you specify the -o option, you
>   don't have access to much of the power of wml. This makes it difficult
>   to the the dest dir correct.

Another idea is to use the VPATH feature of GNU make, but it does not
work.

IMHO you should stay with Makefiles since WMk is not flexible enough for
your needs.  But if some people have suggestions on how to improve WML
and WMk, i will be glad to discuss with them.

Regards

-- 
Denis Barbier
WML Maintainer


Reply to: