nmake knows about ast because ast follows a rational naming convention
PACKAGE_ast=$INSTALLROOT
implies
PACKAGE_ast_BIN = $INSTALLROOT/bin
PACKAGE_ast_INCLUDE = $INSTALLROOT/include/ast
PACKAGE_ast_LIB = $INSTALLROOT/lib
any other package with similar naming conventions will be "known" too
use iffe to configure .c and .h files
iffe can mimic autoconf style macros with
set config
we uses this when converting gnu-build-system makefiles to nmake
nmake makefiles should not require generation
they are the source -- no Nmakefile.in etc.
for most non-ast packages a :PACKAGE: assertion at the top of
the makefile should take care of the -I -L -l option generation
e.g., for X11 builds
:PACKAGE: - X11
the "-" means that X11 is not the main package
the main package controls where headers are installed
this will also add -lX11 as a prerequisite to all command :: assertions
ast makefiles have
:PACKAGE: ast
making ast the main package, so headers will be installed in
$(INSTALLROOT)/include/ast/
and all commands linked with -last
if :PACKAGE: doesn't find a package you can help it with
PACKAGE_foo, PACKAGE_foo_INCLUDE, PACKAGE_foo_LIB path name variables
in the environment or in the makefile or included makefile or --global=makefile
or by explicit .SOURCE.h .SOURCE.a assertions and -l* prerequisites
.SOURCE.h : /usr/local/foo/include
.SOURCE.a : /usr/local/bar/lib
mixed-command :: ... -lbar
On Mon, 1 Jun 2009 21:01:06 -0400 (EDT) [email protected] (Norman Ramsey)
wrote:
> I'm working on porting some of my own code to use iffe and nmake.
> But my code relies on other code that will not be configured using
> these tools. I therefore face the usual problem of figuring out
> what -I options have to be passed to the compiler and what -L and -l
> options have to be passed to the linker in order to compile my code
> against non-AST libraries.
> Reading the documentation for iffe(1), I cannot see how iffe might
> help with this problem. I realize that AST itself does not have this
> problem because it is self-contained: nmake sees all and knows all.
> Does anyone have suggestions for how to use the AST tools to build
> something that depends on non-AST software? I hate GNU autoconf
> and refuse to go in that direction, but I'm hoping something in the
> AST suite would be better than starting from scratch.
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
