[Omake] First pass at Automake.om (was: .PHONY rules in subdirs)

Mon Apr 2 11:18:01 PDT 2007

Tom,

Thanks a lot for the Automake.om - looks pretty good.

A few stylistic comments:

  - For variables like bindir, you might want to bind the $(prefix) 
lazily, so that any changes to prefix would automatically propagate. E.g 
use something like
bindir = $`(prefix)/bin
or even
bindir = $`(dir $(prefix)/bin)

- Is there any reason why you want to glob EXT_CLEAN eagerly upfront? 
This would glob it in the root directory - probably not what you want. I 
would imagine that passing the $(EXT_OCAML_GLOB) directly to rm should 
be good enough.

- Also, you can not delete .omakedb* while OMake is running - it will 
recreate it anyway.

- The variables in lazy rules are expanded lazily, so you do not need to 
use getvar

- You can use "try...default..." instead of "try... catch 
Exception(e)..." when you do not care what exactly failed

- Is there some reason why a single ".DEFAULT : all" upfront does not do 
what you want?

- Naming - other OMake developers have convinced me that replicating the 
AC_* style names was not such a good idea and does not fit stylistically 
with the other function names we have. May be use some prefix like 
AutoOCaml instead of AM_OCaml?

- Just to be on the safe side, it would probably be better to explicitly 
enumerate the variables to be exported at the end of all the functions. E.g.
AutoOCamlProgram(...) =
    ...
    export PROGRAMS

Aleksey

On 29.03.2007 14:32, Tom Murray wrote:

> Hi, Alexsey--
> 
> Thanks very much for your suggestions. The implicit rules do work, 
> though there was some weirdness in the order that dependent phony 
> targets were visited (to have local "hooks" invoked by a main phony 
> target's rules). As a possible alternative to achieving this with 
> implicit rules, I might suggest being able to define a default function 
> to be called at end of each OMakefile context, which would allow setting 
> up these types of rules in the local context. I feel this type of thing 
> is necessary due to OMake's static binding versus the dynamic binding of 
> Make.
> 
> Attached is the beginning of some automake-like functionality, currently 
> just building and installing OCaml programs and libraries (what else 
> would one need :-), along with clean, and check to run unit tests.
> 
> I'd appreciate feedback, suggestions, requests from the list, and I'll 
> move forward on refining and expanding features as time permits.
> 
> Cheers,
> 
> tm
> 
> 
> p.s. As a side note, before I discovered OMake, I had started up a patch 
> to automake for building OCaml targets---it was NASTY! So thanks very 
> much for OMake and freedom from that mess. There are a few nice features 
> in the autotools which I've missed, but I'm happy to see you adding 
> autoconf-like features in recent versions. With a little more work on 
> the automake-emulation, I'm certain that nothing will stop OMake's quest 
> for world domination...
> 
> 
> On 3/29/07, *Aleksey Nogin* <anogin at hrl.com <mailto:anogin at hrl.com>> wrote:
> 
>     Hi Tom,
> 
>     Thanks a lot for a very good question. Let me first go over some of the
>     details before answering it.
> 
>     On 28.03.2007 18:44, Tom Murray wrote:
> 
>      > I'm trying to define a set of default (phony) targets to be
>     active in
>      > every subdirectory of my project, a la automake. For example, I want
>      > "omake clean" to execute some general cleaning code, and I want to be
>      > able to define this once in the root, and not have to copy the
>      > definition to subdirectories.
> 
>     Note that is it easy to define a set of phony _targets_ that would then
>     exist in every project directory - this is what the hierarchy of the
>     .PHONY targets is supposed to give you if you use ".PHONY: clean" in
>     your top-level OMakefile (or OMakeroot) before any of the .SUBDIRS
>     lines.
> 
>     What is harder, as you found out, is to define some "universal" _rules_
>     for those targets.
> 
>      > I find
>      > the current implementation of this a bit strange: When I type "omake
>      > clean" in a subdirectory, it is clearly using the top-level clean
>     rule
>      > in some way, because the invocation does not fail.
> 
>     Here, the "clean" target in the subdirectory is known to be phony, but
>     there are no rules for it (As I understand what you are trying to do,
>     you only have a "clean: ..." rule for the clean target in the project
>     root, but no rules in the subdirectory). In general, OMake is happy to
>     accept any number of rules for phony targets, including not doing
>     anything in case there are no rules at all. So this is what happens -
>     the target is known to be phony, there are no rules for it, it has no
>     dependencies, so OMake does not do anything.
> 
>      > Is there some other mechanism I should be using to achieve what I
>     want
>      > to do?
>     [...]
>      > Must I call an "installMySpecialTargets()"
>      > function at the end of each OMakefile? Please say it ain't so!
> 
>     While using some sort of "InstallMyGlobalRules()" call in every
>     subdirectory is indeed an option, I completely agree that it is not a
>     very good one.
> 
>     The best approach would probably be to use an implicit rule that would
>     then propagate to every subdirectory:
> 
>     --------
>     .PHONY: clean
> 
>     clean%:
>        rm -f *$(EXT_OBJ) *$(EXT_LIB)
> 
>     .SUBDIRS: ...
>     --------
> 
>     In current OMake, there are two imperfections w.r.t. this approach:
> 
>     - You can not define an implicit rule without having a pattern with a
>     wildcard in it, so you end up having to use "clean%" (or "%clean", or
>     some other variation), which might accidentally match something you did
>     not intend to match. I've filed
>     http://bugzilla.metaprl.org/show_bug.cgi?id=658 about this.
> 
>     - If a subdirectory defines its own clean rule (whether implicit or
>     not), the existing one will get shadowed and not executed for that
>     subdirectory. Depending on the situation, you might be interested in
>     keeping both. I've filed http://bugzilla.metaprl.org/show_bug.cgi?id=659
>     discussing this.
> 
>     P.S. One suggestion would be to use something like
> 
>     --------
>     .PHONY: clean
> 
>     EXTRA_CLEANING =
> 
>     clean%:
>        rm -f *$(EXT_OBJ) *$(EXT_LIB) $(EXTRA_CLEANING)
> 
>     .SUBDIRS: ...
>     --------
> 
>     This way any subdirectories can add their own stuff to the
>     EXTRA_CLEANING variable.
> 
>     Aleksey
> 
>     --
>     Aleksey Nogin, Research Staff Member
>     Advanced Technologies Department, Information & System Sciences Lab
>     HRL Laboratories, LLC, Malibu, CA
>     _______________________________________________
>     Omake mailing list
>     Omake at metaprl.org <mailto:Omake at metaprl.org>
>     https://lists.metaprl.org/mailman/listinfo/omake
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Omake mailing list
> Omake at metaprl.org
> https://lists.metaprl.org/mailman/listinfo/omake