Re: Creating/using precompiled headers and static libraries

On Mon, 26 Apr 2004 11:50:36 +0200, Bram Moolenaar
<[email protected]> wrote:

OK, back after experimenting quite a bit with AAP. Lots of new
questions. (I'll post most in separate posts.)

[...]

>> This patch worked great. I'm wondering if there is a case where you
>> might want to add a value twice. I'm thinking there might be, but I
>> can't come up with a good example right now.

>Suppose there is a situation where you want to add a value twice, you
>might get it more than twice without the patch.  Thus using "add_VAR"
>would not work very well anyway.  Unless a much more complicated method
>is used to solve the problem.  Would have to remember that the attribute
>has been used for the current value of the variable in the current scope.
>That's very complicated.

Keeping it the way it is now works for me. Less complication is better,
and the way it is now at least is well defined.

[printing message before a build]

>If it is just a matter of giving a message we could support an attribute
>"buildmessage" that is printed when the target is being build.
>
>A more flexible approach would be to have "pre" and "post" build
>commands.  But that might get complicated.  Aap already offers so many
>mechanisms, adding more will make it even more complex.

Again, less complications is better, but I must admit these would be
nice. They could be used for things like build timing as well, which I
would love to have. Probably not something to spend a lot of time on at
this point, but perhaps it could be considered down the road if it's not
too complex.

I ended up faking a pre-build command like this:

DSBaseClasses_start {virtual} :
   :print *** $target
$BDIR/DSBaseClasses.lib : DSBaseClasses_start

>> >Your changes to support static libraries could be useful for others.
>> >Can the changes to msvc.py be included in the distribution?

>> Absolutely. I'm going to submit it, I just wanted to get it to compile
>> DLLs as well. I also have a DLL subproject that I'll test that on.

>Does this also work with the MSVC tools that are now available for free?
>We could actually make a package for that, to install the compiler when
>needed...

Yes, the free MSVC tools are the same as the commercial ones. (Well, in
theory they should be. MS appears to have released a slightly different
build by mistake, but as far as they know there's no significant
difference.)

-- 
Be seeing you.



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3