Some path prefixes can trigger automount, if we want to ignore them
it might be best to check metaIgnorePaths before we call realpath.
If the raw path does not match, check again after realpath.
Using __CONCAT for identifiers makes it impossible to find their usages
easily, as could be seen in targ.c 1.22 from 2001-07-03. It also
requires that the parts of the identifier are not macros themselves.
No binary change.
A line starting with '======' is parsed as a variable assignment, with
an empty variable name and a value starting with '=====', making that
condition unreachable.
No functional change.
Previously, some line numbers were stored as signed int while others
were stored as size_t. Since line numbers are never negative, use an
unsigned type. Since the maximum file size for makefiles is 1 GB (see
loadfile), unsigned int is large enough even on 64-bit platforms.
Using a single data types reduces the number of type conversions. Using
unsigned int improves compatibility with C90 (printf %u instead of %zu),
which is needed by bmake, which is derived from usr.bin/make.
No functional change.
The variable is set in the context of the target.
This syntax has been supported by gmake for ~ever.
If necessary a makefile can set .MAKE.TARGET_LOCAL_VARIABLES=false
to disable this.
Expose GetBooleanExpr so parse.c can use it.
At least on OpenBSD, "If the src and dst strings overlap, the behavior
is undefined" (since 2013-09-25), so rather use memmove instead.
Keep all other bugs for now, for example "/a/b//../" is reduced to
"/a/b/" instead of the correct "/a/", and for repeated "/././././" in
long paths, the performance is quadratic instead of linear.
Inline the two calls to eat_dots, turning the first into a two-liner.
In meta mode, the affected variable patterns do not contain a '$'.
Outside of meta mode, Global_SetExpand was only called a single time, so
inline that call.
No functional change.
This makes the code easier to read, especially in var.c. It also makes
debugging sessions easier since some debuggers don't show enum
bit-fields symbolically as soon as more than one bit is set.
The code outside var.c is basically unchanged, except that instead of
passing the individual flags, there are 4 predefined evaluation modes.
These suffice for all practical use cases. Only in the implementation
deep inside var.c, the value of the flags keepDollar and keepUndef
differs.
There is no way of passing the struct to EnumFlags_ToString, which means
the ToString function has to be spelled out explicitly. This allows for
fine-tuning the representation in the debug log, to reduce the amount of
uppercae letters.
No functional change.
These variables all belong to a string variable. Connect them using
FStr, which reduces the number of variables to keep track of.
No functional change.
Require caller to pass a buffer and size if they
want the tempfile not unlinked.
Add Job_TempFile to handle blocking signals around
call to mkTempFile, so that meta_open_filemon can use it
in jobs mode.
This change provides for a more natural reading order in the code.
Placing the scope first makes it immediately clear in which context the
remaining parameters are interpreted.
No functional change.
The word "context" does not fit perfectly to the variables that are
associate with a GNode, as the context is usually something from the
outside and the variables are more like properties inherent to the
GNode.
The term "global context" fits even less. Since the thing where
variables are looked up is commonly named a scope, use that term
instead.
This commit only renames the global variables VAR_GLOBAL, VAR_INTERNAL
and VAR_CMDLINE, plus a few very closely related comments. These are:
GNode.vars (because of line breaks)
GNode_Free (dito)
varname-make_print_var_on_error.mk
varname-make_print_var_on_error-jobs.mk
The debug message in Var_Stats is left as-is since there is no unit test
for it yet.
The other renamings (variable names "context", "ctxt", as well as
further comments) will be done in a follow-up commit.
The function names now follow the naming scheme from the other functions
that handle variables.
There are several calls that remain syntactically unchanged but that
omit the call to strchr('$') now. Since all these calls use constant
variable names, there is no functional change.
All callers with a variable name that is guaranteed to not contain a
dollar sign have been converted to call Global_Append instead of the
previous Global_AppendExpand. After that, Global_AppendExpand was
unused, therefore it was effectively just renamed.
There are many places where global variables are set or appended to. To
reduce clutter and code size, encode the VAR_GLOBAL in the function
name.
The word Expand in the function names says that the variable name is
expanded. In most of the cases, this is not necessary, but there are no
corresponding functions Global_Set or Global_Append yet.
Encoding the information whether the name is expanded or not in the
function name will make inconsistencies obvious in future manual code
reviews. Letting the compiler check this by using different types for
unexpanded and expanded variable names is probably not worth the effort.
There are still a few bugs to be fixed, such as in SetVar, which expands
the variable name twice in a row.
Most of the make code already followed the style of explicitly writing
(ptr != NULL) instead of the shorter (ptr) in conditions.
The remaining 50 instances have been found by an experimental,
unpublished check in lint(1) that treats bool expressions as
incompatible to any other scalar type, just as in Java, C#, Pascal and
several other languages.
The only unsafe operation on Boolean that is left over is (flags &
FLAG), for an enum implementing a bit set. If Boolean is an ordinary
integer type (the default), some high bits may get lost. But if Boolean
is the same as _Bool (by compiling with -DUSE_C99_BOOLEAN), C99 6.3.1.2
defines that a conversion from any scalar to the type _Bool acts as a
comparison to 0, which cannot lose any bits.
This macro was supposed to return a boolean expression all the time, it
just hadn't been implemented this way. This resulted in wrong output
for the test sh-flags, in compilation modes -DUSE_UCHAR_BOOLEAN and
-DUSE_CHAR_BOOLEAN, since in ParseCommandFlags, the expression
DEBUG(LOUD) didn't fit into a boolean.
Do not increment a null pointer.
Do not assign to a variable twice in the same statement. To be fair,
this may be safe because of the sequence point when the function is
called, but anyway, it looks too close to undefined behavior.
This is needed to compile bmake with GCC 2.8.1 on SunOS 5.9.
To support ancient systems like this, the whole code of usr.bin/make is
supposed to use only ISO C90 features, except for filemon, which is not
used on these systems.
The function basename from POSIX has a few unfortunate properties, it is
allowed to return a pointer to static memory. This is too unreliable,
therefore this trivial own implementation.
rillig