Re: AAP static libraries tools

On Mon, 05 Apr 2004 14:59:39 +0200
Bram Moolenaar <[email protected]> wrote:

> Fred Schoenahl wrote:
> 
> > thanks for AAP. Great (useful)  project! I have been using SCons,
> > but I found the portability issues and configure-like steps not that
> > clear.
> 
> I'm glad you like Aap better than SCons.  Do keep in mind that SCons
> has been around for a longer time and its tools have been improved a
> bit more.

Yes, I should have said: the orientation of a-a-p "better fits my needs"
;) 

(...)
> The [bcc]] tool can be extended by adding a few lines.  You can see
> that"C_BUILD_ACTION" is used.  For libraries "BUILDLIB_ACTION" is to
> be set to "buildlib_bcc".  And define the "buildib_bcc" action.  The
> examples in other files should give enough hints how to do this.

Oh this is what I tried but I did not know which "rule" to change - had
not seen any buildlib_bcc. This should be trivial, true.

> On the other hand, if the only thing that's different is the name of
> the executable, then having bcc.py set $AR to "tlib" might work.

Ok, I missed the AR variable - as typical unix tool, had been looking
around the LIB* variables...

> If you manage to make this work, please send me the updated bcc tool
> to include in the distribution.

Ok
> > Note :  if I use gcc w. dgjpp (:usetool gcc), the linker is LIB.exe
> > as well, and not AR
> When using gcc the default actions are used, which are defined in
> Exec/default.aap.  It should use "lib" then, unless it thinks it is
> not running on "nt".  Are you using the Cygwin version of Python
> perhaps? You can override the program with the $AR variable.

Yes, just found not "clean" to have something compiled with bcc and
linked with the borland linker, but if I get the bcc tool hack working,
it should do the trick.

> > 2)
> > Then if the project tree is the same on linux/unix and windows, it
> > should not be required to rewrite the subdirectory indicator :
> > 
> > Linux :
> > 	:lib mylib: src/mysource.c
> > 
> > Windows:
> > 	:lib mylib: src\mysource.c
> > 
> > If I remember well SCons uses '/' even on windows and translates to
> > the right format according to the platform. The only solution I have
> > found is to do an @if  statement, because aap complains on windows
> > if I use "/". 
> 
> Aap has the same intention: always use forward slashes in file names.

In fact I saw this in the TODO list just after posting, sorry...

> But for MS-Windows system commands often backslashes have to be used.
> This should be handled where the system command is invoked.
> I'm afraid we don't have a simple method for this yet.  You would have
> to use a Python function to replace slashes with backslashes.
> 
> There are two possible ways to make this simple:
> 1. Use a function.  Example:
> 	:sys compile `backslash(source)` > `backslash(target)`
> 2. Use a special character after the $.  Example:
> 	:sys compile $/source > $/target
>    Unfortunately, the more obvious $\var is already being used for
>    escaping special characters.

may I add

  3. Allow both (transfer problems to developers ;))  
  4. Use | (bar) unless already used like : 
	:sys compile src|source.c 

I would love the src|subproject|main.c, but as I see you use OR-similar rules for
"oneof", it may be problematic to make | (conventional OR) reserved for
the future

> > 3)
> > I have a test directory that uses the recently created lib, but I
> > don't know how to write a reference to this lib in a platform
> > independant manner :  I have used  
> >
> > 	LIBS = ../lib/$?LIBPREmylib$?LIBSUF
> > 
> > so that if the system produces mylib.lib it will be taken as well as
> > libmylib.a on linux. The problem is that the concatenation of
> > $?LIBPREmylib$?LIBSUF doesnt work and produces "../lib/.lib" on
> > windows How to write it in a correct manner?
> 
> Use parenthesis:
>  	LIBS = ../lib/$?(LIBPRE)mylib$?LIBSUF

Yeah, thanks for the trick !
 
> > Thanks for your help, long life to the project (I especially expect
> > a lot from the :conf  commands..)

> It looks like Aap is the only portable system with automatic
> configuration.  

This is a real skill, because if I consider the makefile language
useful, the autoconf language is very complicated and looks awful (never
wanted to have my hands dirty with it ;)) moreover it uses M4, a third
language that has to be available in the platform, and ac_ scripts that
have variable locations...

> That could be a "selling feature".  

Definitely yes.

> I have thought about
> expanding it, but didn't find time to actually work on it.  

The project isn't to its end, if I can, I ll check what I can do... have
to learn advanced python first !

> Ultimately
> it would become a complete autoconf replacement.  But let's first try
> adding the most useful stuff.  What would you need now?

Oh I'll just propose that :

- Binding to pkg-config in two ways : smtg like
	:conf config: mytool
which tests e.g. the existence and output of 
	mytool-config --version
or 
	pkgconfig --version mytool

and another useful tool would be a parser like SCons ParseConfig() that
works like 

parseconfig(`mytool-config --libs --flags`) 
and sets LIBS, INCLUDE and other flags as required. 

Maybe combine both?

I'll see what I can do, have some experience with python, but not on
system related computing ... so have to explore how aap is done first...
Thanks a lot,
Fred



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click