Subject: Re: Targets and projects update
Newsgroups: gmane.comp.lib.boost.build
Date: 2002-05-11 18:41:00 GMT (6 years, 12 weeks, 5 days, 13 hours and 57 minutes ago)
----- Original Message ----- From: "Vladimir Prus" <ghost <at> cs.msu.su> > I'll try to clarify. There are abstract, virtual and actual targets, which > definitions are given at the top of the file. > > Abstract targets form a long hierarchy. First, there are > project-targets, they are just containers for main targets. > Main-targets, also derived from abstract-target, are just containers for > variants, which are derived from 'abstract-target'. Classes that will be used > for variants are actually the most important. There's class with common > functionality 'basic-target' and I plan to have two derived classes. > > First, 'make-target' will correspond to 'make' rule invocation. Second, > 'typed-target' will correspond to rules such as "exe", "lib", etc. where the > target type is defined. Good, that is perfectly clear! A UML diagram would help. > Maybe it would be better to describe how tagets will be generated. > > 1. A 'project-target' for project in "." is retrived and its 'generate' rule > is called. > 2. For all main targets and for all subproject, call they 'generate' rules > 3. In each main targets, 'generate' rule for each variant is called. Now only > one can return non-empty list of virtual targets. I presume this is because generate takes a single build configuration (element of an expanded build request) as a parameter, and you only want to build on variant per element of the build request (?). > 4. Class for main target variant can do anything in general, but those > derived from 'basic-target' will: > - refine required properties with requirements > - build source targets Another target type! What's a "source target"? (and what does "build" mean, precisely?) > - call 'construct' rule that will be declared in the most derived class Which, in general, does what? > > So, is local-name really the same as the name of the main target? > > Yes. I used this name for variable because of mental connection with > 'declare-local-target'. I'd prefer "name", I think. Is this also a target id? If so, id is better (more formal). > > # Generates virtual targets for this abstract target which match > > # 'properties' as closely as possible. > > > > Hmm, what does "as closely as possible" mean? > > Oh... We need to decide this. If user gives some build request, are there any > constaints on what properties can be used for building, except that they must > be link compatible with the requested ones? I don't see why there should be additional constraints. Did you have something in mind? > > # always bring in the rules defined from this module, so that > > # users can easily call "inherit", for example. > > import class : * ; > > Welll.... but when I comment that line out, project-test2.py fails! Shouldnt' > the fragment you quote be moved to the 'instance' rule? You're probably right. Why don't you make that change? > > 1. the trick with "@" is possibly too tricky. It took me a long > > time to grok, and at least needs more explanation. > > The actual problem is that we seem to need a list where each element can be > list itself. How do we implement that? It ain't easy; most approaches are hacks. Your trick might be as good as it gets. You could write a "Jam expression parser" and build lists as space separated elements. Of course you'd need to quote any embedded spaces. > > 2. It looks like @error messaages are just discarded. Intentional? > > If so, say so in a comment. No comment from you on this? > > I tried to answer your questions posed in the comment above > > basic-target.generate the other day. Did that work for you? I'm > > actually unclear on the relationship of this generate rule to the > > search process we came up with in the design process. > > Oops! I though I've responded that email of yours, but I don't see that > message either in sent or in drafts. While I'm looking for it, it's enough to > say that I'm unclear the relationship either.... so this rule might need > change when we start implementing generators. Hmm... OK, I'm flexible, but we should clarify that soon. > > I object to the idea of naming a rule "recurse": it just describes an > > implementation technique, not what the rule does. Can you do something > > more descriptive? > > 'generate-source' is what I came up with. It's a start. -Dave