History log of /openbsd/usr.bin/make/var.c (Results 51 – 75 of 107)
Revision Date Author Comments
# f75387cb 03-Jun-2003 millert <millert@openbsd.org>

Remove the advertising clause in the UCB license which Berkeley
rescinded 22 July 1999. Proofed by myself and Theo.


# c848b768 05-Jun-2002 espie <espie@openbsd.org>

tweak quick_lookup for a faster path.
okay millert@


# f7923656 23-May-2001 espie <espie@openbsd.org>

Mostly clean-up:
- cut up those huge include files into separate interfaces for all modules.
Put the interface documentation there, and not with the implementation.
- light-weight includes for needed

Mostly clean-up:
- cut up those huge include files into separate interfaces for all modules.
Put the interface documentation there, and not with the implementation.
- light-weight includes for needed concrete types (lst_t.h, timestamp_t.h).
- cut out some more logically separate parts: cmd_exec, varname, parsevar,
timestamp.
- put all error handling functions together, so that we will be able to
clean them up.
- more systematic naming: functioni to handle interval, function to handle
string.
- put the init/end code apart to minimize coupling.
- kill weird types like ReturnStatus and Boolean. Use standard bool (with a
fallback for non-iso systems)
- better interface documentation for lots of subsystems.

As a result, make compilation goes somewhat faster (5%, even considering
the largish BSD copyrights to read). The corresponding preprocessed
source goes down from 1,5M to 1M.

A few minor code changes as well: Parse_DoVar is no longer destructive.
Parse_IsVar functionality is folded into Parse_DoVar (as it knows what an
assignment is), a few more interval handling functions. Avoid calling
XXX_End when they do nothing, just #define XXX_End to nothing.

Parse_DoVar is slightly more general: it will handle compound assignments
as long as they make sense, e.g., VAR +!= cmd
will work. As a side effect, VAR++=value now triggers an error
(two + in assignment).
- this stuff doesn't occur in portable Makefiles.
- writing VAR++ = value or VAR+ +=value disambiguates it.
- this is a good thing, it uncovered a bug in bsd.port.mk.

Tested by naddy@. Okayed millert@. I'll handle the fallback if there is
any. This went through a full make build anyways, including isakmpd
(without mickey's custom binutils, as he didn't see fit to share it with me).

show more ...


# 33821261 15-May-2001 espie <espie@openbsd.org>

Don't go beyond end of string.
Handles unterminated variables, and fixes regression test #10


# 04ed836e 03-May-2001 espie <espie@openbsd.org>

Synch with my current work.
Numerous changes:
- generate can build several tables
- style cleanup
- statistics code
- use variable names throughout (struct Name)
- recursive variables everywhere
- fa

Synch with my current work.
Numerous changes:
- generate can build several tables
- style cleanup
- statistics code
- use variable names throughout (struct Name)
- recursive variables everywhere
- faster parser (pass buffer along instead of allocating multiple copies)
- correct parser. Handles comments everywhere, and ; correctly
- more string intervals
- simplified dir.c, less recursion.
- extended for loops
- sinclude()
- finished removing extra junk from Lst_*
- handles ${@D} and friends in a simpler way
- cleaned up and modular VarModifiers handling.
- recognizes some gnu Makefile usages and errors out about them.

Additionally, some extra functionality is defined by FEATURES. The set of
functionalities is currently hardcoded to OpenBSD defaults, but this may
include support for some NetBSD extensions, like ODE modifiers.

Backed by miod@ and millert@, who finally got sick of my endless patches...

show more ...


# 452771c2 02-Mar-2001 espie <espie@openbsd.org>

Use the ohash_* that's now in libc.


# fff2e33b 07-Dec-2000 espie <espie@openbsd.org>

Forgot to copy end of name in nested variable names, so that
${BC_${A}} worked but not ${${A}_BC}.
Noticed by fries@


# 6bba1612 24-Nov-2000 espie <espie@openbsd.org>

Take advantage of VarModifiers_Apply, which can parse a variable spec
and expand it directly, without needing a variable context.

Use it in Var_SubstVar, so that .for loops values don't need to be e

Take advantage of VarModifiers_Apply, which can parse a variable spec
and expand it directly, without needing a variable context.

Use it in Var_SubstVar, so that .for loops values don't need to be entered
into any context nor looked up.

This speeds up .for loops some, and avoids nasty variable capture
side-effects.

Ok'd millert@, miod@, naddy@ (naddy spotted a problem with the first
version of that change).

show more ...


# ac3def53 13-Oct-2000 espie <espie@openbsd.org>

esetenv: does a setenv and bails out if error.


# 761218d5 14-Sep-2000 espie <espie@openbsd.org>

Some systematic clean-up.
- UNUSED macro that expands to __attribute__((unused)) for gcc
- move rcsid around so that they can be tagged UNUSED.
- activate -Wunused.
- use UNUSED instead of kludgy jun

Some systematic clean-up.
- UNUSED macro that expands to __attribute__((unused)) for gcc
- move rcsid around so that they can be tagged UNUSED.
- activate -Wunused.
- use UNUSED instead of kludgy junk for function arguments.
- add extern to all extern prototypes.
- update comments in lst.h.
- clean up var.c a little bit, constifying arguments, updating comments...

show more ...


# 12b0f982 21-Aug-2000 espie <espie@openbsd.org>

Var_Append needs to set v for DEBUG(VAR) to work.
Obvious fix.
Problem reported by Gregory Steuck, thanks a lot !


# 252c50ab 18-Jul-2000 espie <espie@openbsd.org>

Handle MAKEFLAGS variation mandated by POSIX.

Code to pass variable definitions to submakes through make flags.
Not activated yet, need to fix src/ first.


# b05a8d2f 17-Jul-2000 espie <espie@openbsd.org>

parse embedded variable specs, e.g., ${VAR_${SUB}}

- need braces, as we don't want to change what $$A means,
- this assumes this kind of construct is very infrequent, thus
this does NOT copy the var

parse embedded variable specs, e.g., ${VAR_${SUB}}

- need braces, as we don't want to change what $$A means,
- this assumes this kind of construct is very infrequent, thus
this does NOT copy the variable name needlessly.
- the expansion code is in a separate function for clarity.

Reviewed by miod@, as previous patches.

show more ...


# 66a2e33a 17-Jul-2000 espie <espie@openbsd.org>

- let VarModifiers_Apply accept NULL string gracefully,
- simplify Var_Parse: use varfind, then leverage on the result
to recognize `special case' dynamic parsing.

VarModifiers_Apply need to be call

- let VarModifiers_Apply accept NULL string gracefully,
- simplify Var_Parse: use varfind, then leverage on the result
to recognize `special case' dynamic parsing.

VarModifiers_Apply need to be called on NULL strings, to be able to parse
modifiers applied to non-existent variables.

(Alternately, we could call VarModifiers_Apply on a dummy string, but
this is less efficient).

show more ...


# 6b5ae482 17-Jul-2000 espie <espie@openbsd.org>

Major unobfuscation: split var modifiers handling to a separate file.
This does finally make var handling somewhat readable.


# fe93b915 17-Jul-2000 espie <espie@openbsd.org>

separate modifiers handling from Var_Parse into a separate
VarModifiers_apply function.

for env lookup, create variable structure first, so that we can get away
without terminating the variable name

separate modifiers handling from Var_Parse into a separate
VarModifiers_apply function.

for env lookup, create variable structure first, so that we can get away
without terminating the variable name in main Var_Parse.

show more ...


# f0eb7fef 17-Jul-2000 espie <espie@openbsd.org>

This does replace Str_Match with a better routine, which handles negated
intervals, and \\ in intervals.

Accordingly, var.c no longer needs to copy the :Marg to replace \: with :

We don't use fnmat

This does replace Str_Match with a better routine, which handles negated
intervals, and \\ in intervals.

Accordingly, var.c no longer needs to copy the :Marg to replace \: with :

We don't use fnmatch(3) because of various optimizations which are harder
to achieve in a generic setting.

Also add regression suite for the Str_Match function.

show more ...


# 103cd81c 17-Jul-2000 espie <espie@openbsd.org>

Constify a few functions, propagated from VarModify.
Replace a few int -> size_t

Reviewed by miod@


# 667645fc 17-Jul-2000 espie <espie@openbsd.org>

- recognize that FIND_CMD and FIND_GLOBAL are always used together,
- introduce VarFind_interval function. This avoids having to copy variable
names in VarParse,
- expose internals of VarFind* functi

- recognize that FIND_CMD and FIND_GLOBAL are always used together,
- introduce VarFind_interval function. This avoids having to copy variable
names in VarParse,
- expose internals of VarFind* function (not used yet, but this will avoid
multiple lookups in VarParse),
- constify a few functions.

Reviewed by miod@

show more ...


# 03bc119a 23-Jun-2000 espie <espie@openbsd.org>

This is the speed-up patch, which doubles make speed (almost).

Use the open hashing functions for global contexts instead of List in
var.c.

All the preliminary work to trim down local contexts mean

This is the speed-up patch, which doubles make speed (almost).

Use the open hashing functions for global contexts instead of List in
var.c.

All the preliminary work to trim down local contexts means that we don't
suffer from the heavy initialization work that a hash table entails.

There is some make kludgery to:
- build the hashing functions as a library,
- recreate hashconsts.h, even if make depend was not invoked.

One point of the hashing scheme written was to separate the computation
of the hash function, and the hash lookup itself. This is very convenient
for make, because of those pesky special variables. hashconsts.h is there
to pre-hash the correct values, which replaces a few expensive string
comparisons with quick hash value comparisons, followed by one expensive
string comparison. The modulus MAGICSLOTS chosen in the Makefile is
ad-hoc: it is small enough to write a small switch without collision,
and will need changing if the hash function changes...

The function quick_lookup is the most important:
it either returns an index, for a local variable, or it does compute a
hashing value, and returns -1.

Another somewhat controversial decision is the use of string intervals.
This avoids either copying a string, or twiddling with a byte for cases
such as ${VAR}.

Finally, the variable name is stored within the variable itself. Since
a given variable name never changes, this makes sense. All that was needed
was a hash library with support for this. Note that the hashing table
holds only a variable pointer AND the corresponding hashing value, WITHOUT
a modulo hashtablesize. Two reasons:
- hash resizes can be done faster, without having to recompute hashing values.
- locality of access. The hash table fits into memory without problem. Once
a candidate slot is found, we check the complete hashing value. Probability
of a collision is very small (32 bits...). So bringing up the whole
variable in memory at once is good: the name will almost always match, in
which case we want the variable value as well, so it makes sense to put
them together.

The ohash functions implement open hashing, as described in Knuth, but with
a variable table size. Choosing powers of 2 sizes does not yield more
collisions, but it makes the hashing scheme much simpler. The thresholds at
which to expand/shrink the tables seem to work well in practice. The
default sizes were chosen such that the tables hardly ever shrink or expand
anyways (though I've tried with smaller/larger sizes to verify that the
shrinking/expanding worked correctly): larger Makefiles hold roughly
500/600 variables, which fits without trouble into a 1024-sized variable.

Disregard #ifdef STATS_HASH, this is some internal scaffolding I'm using
to measure make performance.

The only known issue with open-hashing is that deletions cannot create
empty slots, but do leave slots marked as `occupied once' so that lookup
works. We use a well-known optimization which records those pseudo-empty
slots while looking up values. If the value is not found, the pseudo-empty
slot is returned to be filled. If the value is found, it is swapped with
the pseudo-empty slot. This is an improvement in both cases, since this
shortens the length of lookup chains, eventually pushing the pseudo-empty
slots to the end.

Reviewed by millert@ and miod@

show more ...


# fd0e26bf 23-Jun-2000 espie <espie@openbsd.org>

This patch separates local contexts from global contexts for good.
Apart from a few casts, VAR_GLOBAL and friends are separate
data structures, so we use a small array for local variables.

We also j

This patch separates local contexts from global contexts for good.
Apart from a few casts, VAR_GLOBAL and friends are separate
data structures, so we use a small array for local variables.

We also junk allVars, since TargFreeGN can release local nodes,
and var.c has explicit lists for its variables already.

Reviewed millert@ and miod@.

show more ...


# 2305b5b7 23-Jun-2000 espie <espie@openbsd.org>

In various places, VAR_CMD is used to actually mean `no real context',
since lookup will start with VAR_CMD in any case.
This fixes VarFind and Var_Parse to handle ctxt == NULL correctly, and
replace

In various places, VAR_CMD is used to actually mean `no real context',
since lookup will start with VAR_CMD in any case.
This fixes VarFind and Var_Parse to handle ctxt == NULL correctly, and
replace those confusing VAR_CMD with proper NULL pointers.

This patch also handles three small details:
- .CURDIR is necessarily set in VAR_GLOBAL,
- suffix handling for archives copies two hard-coded variables, for
which it can use a quick path,
- typos in TargFreeGN.

Reviewed millert@, miod@.

show more ...


# 1b3f956e 23-Jun-2000 espie <espie@openbsd.org>

Once those special variable are taken care of, other Var functions can take
the GNode's context directly. We rename that special Lst to `SymTable *'
in prevision of things to come.

Along the line,

Once those special variable are taken care of, other Var functions can take
the GNode's context directly. We rename that special Lst to `SymTable *'
in prevision of things to come.

Along the line, we lose the special GNodes affected to VAR_CMD, VAR_GLOBAL,
VAR_ENV, which become simple Lsts... This is not a problem, except when
getting to a context's name for debugging (handled very nicely by
offsetof).

Again, this is a preparatory patch, which does not gain anything except
for cleaning up issues...

Reviewed by millert@ and miod@, like the previous patch

show more ...


# 36dc8498 23-Jun-2000 espie <espie@openbsd.org>

Start of variable fixes and speed-ups.

This patch may seem a bit non-sensical at first. It simply introduces some
new interface. Specifically, recognizes that some variable names
(.TARGET/$@, .OODAT

Start of variable fixes and speed-ups.

This patch may seem a bit non-sensical at first. It simply introduces some
new interface. Specifically, recognizes that some variable names
(.TARGET/$@, .OODATE/$?, .ALLSRC/$>, .IMPSRC/$<, .PREFIX/$*, .ARCHIVE/$!,
.MEMBER/$%) are `special' (the actual variables which are local to a
target, e.g. GNode).

Currently, The Varq functions (for Varquick access) are only stubs to the
normal functions.

This fixes a very important detail before proceeding to turn variable lists
into hash tables: if every GNode holds a hash table, initialization times
for those will be very costly. But generic GNodes only hold those seven
special variables... which can be stored directly into a small array;
the only general cases are the environment, the command line and
global variables.

show more ...


# 34a5a16d 17-Jun-2000 espie <espie@openbsd.org>

This patch introduces a distinction between
Lst_Init (constructor) and Lst_New (allocation + construction)
Lst_Destroy (destructor) and Lst_Delete (deallocation + destruction),
and uses that to turn

This patch introduces a distinction between
Lst_Init (constructor) and Lst_New (allocation + construction)
Lst_Destroy (destructor) and Lst_Delete (deallocation + destruction),
and uses that to turn most dynamic allocation of lists (Lst pointers)
into static structures (LIST).

Most of this is mundane, except for allGNs in targ.c, where the code must
be checked to verify that Targ_Init is called soon enough.

Lst_New is a temporary addition. All lists will soon be static.

Reviewed by millert@, like the previous patch.

show more ...


12345