Re: [jamboost] Boost.Build stress test

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-03-21 06:20:16

Hi Ali,

> > Do you think it's so complex that regular user won't ever understand it?
> > Or there's something wrong with docs which can be improved?
>
> My only point was that the BB system shares the same problem as my
> master makefile system in that the guts of it is unapproachable by a
> regular user (as opposed to a power user), so if it is not working as
> documented for some reason, the user gets frustrated and has to ask or
> look for help instead of being able to diagnose it easily and
> immediately. Users don't like that.

I understand you now.

> I think the documentation is already okay for using the system...when
> it works. Bjam already has some good diagnostic features (e.g. -d+2)
> and others could be addressed later. The matter is secondary for me
> at the moment because I've already put in the effort to understand
> and, for now, I just want to get it to work on existing
> projects...I'll worry about regular users later.

OK.

> > > (However, note that it took me 2-3 weeks to figure out how to
> > > write those 236 lines!...Jam/BB is *very* difficult to learn.)
> >
> > If you tell what can be improved, we'll try to.
>
> The best design document for learning a complex system is a layering
> diagram. I created one for BB for my own use using the "import"
> declarations in the new/*.jam files (I think it's not perfect because
> you don't have to import to use rules from another module, right?).
> Anyway, even if not perfect, that was finally very helpful in
> directing my understanding of the system. I've attached my layering
> diagram if you want to see it.

Further than that, I'd like to see something like it in the V2 docs, if you 
don't mind. Some modules needs to be moved between layer, IMO, but
in general, it's quite correct. 

> > I'm very interested in do-nothing timing. Can you run "bjam -d+10" on an
> > unmodified tree and send me the output. This will tell what consumes most
> > time.
>
> Attached.

Dave already commented about this. 2:30 of the delay time is spend sorting 
properties... which was added when I was fixing Jurgen's performance problems 
;-) I believe that adding a new builtin can improve the situation 
considerably, but let's first see how Dave's patch works out.

It's very good that we have profiling support. It's surprising how performance 
problems are in the most unexpected places.

> > I see that all problems with those are listed below, so I'll comment
> > later. May I suggest one experiment? Go to builtin.jam, find
> > 'compile-action' rule and inside it 'adjust-properties'. Change the
> > return line to read:
> >
> > return $(properties) ;
> >
> > and try again. This might not reduce command line length sufficiently,
> > but it's interesting to check.
>
> I skipped this because your fix earlier in the week solved my archive
> problem and Juergen's fix to jam.h:MAXLINE solved the rest of the
> problems. Looks like it was a compiled-in Jam limitation rather than
> a shell limitation.

I think that when we take care of the sorting issue, it would be nice to 
try this, anyway. I suspect that it might decrease header scanning time.

> > Do you mean that current dir for all compiler invocations is equal to
> > the directory where you've started bjam? I understand you, but the
> > change is controversial. For one thing, it will immediately broke
> > *compilation* mode in Emacs --- the error message will use file names
> > relative to some other directory than the one where you've run the
> > compilation.
>
> I sympathize because I am an Emacs user, but I have to say that this
> is an Emacs problem and ought ideally to be solved by providing elisp
> code to do Emacs-based compiles. 

It's still controversial. Build system should do what the user wants, as a 
general rule, and I'd rather not ask all emacs users to change their 
settings :-(

> A user of my system encountered a
> similar problem because my system does change directory before
> building...I will check to see what his solution was (if any).

OK. 

> > > For a DLL, make an Archive
> > > incrementally as above and link to the Archive.
> >
> > Oh... is this common approach for creating DLL with too many sources?
> > It looks like very general and usefull. One question, though: do you know
> > if it works on Windows. I mean, can you use "_declspec(export)" on symbol
> > in static lib and then have the symbol exported when the static link
> > becomes dynamic?
>
> I don't know if it is common, but it is a workaround that I have used.
> It will work on Windows/GCC, but I assume you mean will it work on
> MSVC. On MSVC, you will have to provide a ".def" file with "EXPORT"
> statements and I'm not sure if there is a standard automatic way to
> create this file. But we can cross this bridge when we come to it.

Okay. I think I've closed achive creating problem already. Need to address 
DLLs in future.

- Volodya