As explained here, I like to create file objects in subdirs, and library / executables in the top-level file. However, since all the variables end up in global scope, two subdir files could accidentally use the same variable names. For example:
# Top-level meson.build
subdir('src/abc')
subdir('src/def')
# src/abc/meson.build
my_files=files('1.c','2.c')
# src/def/meson.build
my_files=files('3.c','4.c')
I want meson to throw an error when src/def/meson.build tries to assign a value to my_files. Is this possible in Meson 0.50?
Reassigning variables is rather legitimate operation in meson, so it looks as it is not possible to generate error in standard way. One way of avoiding this problem is following some naming rules e.g. according to folders/sub-folders' names (abc_files, def_files in your case).
But if you really need to have variables with the same name and make sure they are not reassigned, you can use is_variable() function which returns true if variable with given name has been assigned. So, place the following assert before each assignment:
assert(not is_variable('my_files'), 'my_files already assigned!!!')
my_files=files('3.c','4.c')
A question for CMake experts out-there.
According to the CMake function documentation a function simply does not return anything. To change variable values one has to pass it to the function, and inside the function set the new value specifying the PARENT_SCOPE option.
Fine, this is a well-known feature of CMake.
My question here is not about the how, rather on why: why CMake functions do not return values? What is the idea behind?
For example, a function cannot be used inside a if expression, or called inside a set command.
If I remember correctly, it is the same with autotools, therefore I do not think it is like this just by chance.
Is there any expert that knows why?
You can find a partial answer by Ken Martin in a message from the CMake's mailing list:
With respect to the general question of functions returning values it
could be done but it is a bit of a big change. Functions and commands
look the same (and should act the same IMO) to the people using them.
So really we are talking about commands returning values. This is
mostly just a syntax issue. Right now we have
command(arg arg arg
)
to support return values we need something that could handle
command (arg command2(arg arg) arg arg
)
or in your case
if(assertdef(foo))
or in another case
set(foo get_property(
))
etc. This hits the parser and the argument processing in CMake but I
think it could be done. I guess I’m not sure if we should do it.
Open to opinions here.
I am referring the official doc to use find_library() and my cmake version is 3.9.1.
In short, my find_library() only deals with the first library name and ignore the rest.
For example, when I do something like,
find_library (var NAMES libname1 libname2 PATHS libpath)
var will only get the full path-name of library libname1 not the counterpart of libname2. Both the libraries are placed correctly in libpath. In fact, if I reverse the order as NAMES libname2 libname1, var will only get the full path-name of library libname2
Any suggestion?
The find_librarycommand finds a library by trying the NAMES one after another. So the NAMES are synonyms for the library (e.g. libjpg libjpeg). After the first match it saves the path to the library in the variable var. You need to use two find_library calls to accomplish what you are after.
I'm writing a tool to add variables to a2l file, the input is elf file.
For searching which compile unit (CU) has the variable, I have to search through all CUs (till meet the variable).
Because the SW is very big, it takes time to find a variable.
I would like to know if there's any faster way to know which CU the variable is defined ?
The DWARF standard includes an optional section, .debug_pubnames, that provides name-to-offset translation for global objects and functions.
Another approach is to use the symbol table. If it has an entry for the variable then you can use its address with the optional .debug_aranges section or, failing that, read every DW_TAG_compile_unit looking for the one with the enclosing address range.
I am wondering if there exists already some naming conventions for Ocaml, especially for names of constructors, names of variables, names of functions, and names for labels of record.
For instance, if I want to define a type condition, do you suggest to annote its constructors explicitly (for example Condition_None) so as to know directly it is a constructor of condition?
Also how would you name a variable of this type? c or a_condition? I always hesitate to use a, an or the.
To declare a function, is it necessary to give it a name which allows to infer the types of arguments from its name, for example remove_condition_from_list: condition -> condition list -> condition list?
In addition, I use record a lot in my programs. How do you name a record so that it looks different from a normal variable?
There are really thousands of ways to name something, I would like to find a conventional one with a good taste, stick to it, so that I do not need to think before naming. This is an open discussion, any suggestion will be welcome. Thank you!
You may be interested in the Caml programming guidelines. They cover variable naming, but do not answer your precise questions.
Regarding constructor namespacing : in theory, you should be able to use modules as namespaces rather than adding prefixes to your constructor names. You could have, say, a Constructor module and use Constructor.None to avoid confusion with the standard None constructor of the option type. You could then use open or the local open syntax of ocaml 3.12, or use module aliasing module C = Constructor then C.None when useful, to avoid long names.
In practice, people still tend to use a short prefix, such as the first letter of the type name capitalized, CNone, to avoid any confusion when you manipulate two modules with the same constructor names; this often happen, for example, when you are writing a compiler and have several passes manipulating different AST types with similar types: after-parsing Let form, after-typing Let form, etc.
Regarding your second question, I would favor concision. Inference mean the type information can most of the time stay implicit, you don't need to enforce explicit annotation in your naming conventions. It will often be obvious from the context -- or unimportant -- what types are manipulated, eg. remove cond (l1 # l2). It's even less useful if your remove value is defined inside a Condition submodule.
Edit: record labels have the same scoping behavior than sum type constructors. If you have defined a {x: int; y : int} record in a Coord submodule, you access fields with foo.Coord.x outside the module, or with an alias foo.C.x, or Coord.(foo.x) using the "local open" feature of 3.12. That's basically the same thing as sum constructors.
Before 3.12, you had to write that module on each field of a record, eg. {Coord.x = 2; Coord.y = 3}. Since 3.12 you can just qualify the first field: {Coord.x = 2; y = 3}. This also works in pattern position.
If you want naming convention suggestions, look at the standard library. Beyond that you'll find many people with their own naming conventions, and it's up to you to decide who to trust (just be consistent, i.e. pick one, not many). The standard library is the only thing that's shared by all Ocaml programmers.
Often you would define a single type, or a single bunch of closely related types, in a module. So rather than having a type called condition, you'd have a module called Condition with a type t. (You should give your module some other name though, because there is already a module called Condition in the standard library!). A function to remove a condition from a list would be Condition.remove_from_list or ConditionList.remove. See for example the modules List, Array, Hashtbl,Map.Make`, etc. in the standard library.
For an example of a module that defines many types, look at Unix. This is a bit of a special case because the names are mostly taken from the preexisting C API. Many constructors have a short prefix, e.g. O_ for open_flag, SEEK_ for seek_command, etc.; this is a reasonable convention.
There's no reason to encode the type of a variable in its name. The compiler won't use the name to deduce the type. If the type of a variable isn't clear to a casual reader from the context, put a type annotation when you define it; that way the information provided to the reader is validated by the compiler.