Based on command line option (CLO) `-e/--declare-enums-as` that
selects the way how to define C enums and bit fields.
Added support for 5th options in addition 4 already implemented.
1. `IntConst`: No type, just use integer non typed constants. This was
already implemented, but not easily selected at CLI.
2. `TypedIntConst`: Use non strict type aliases and typed constants.
This was already implemented, selected by default in the code.
3. `IntAliasConst`: Use strict type aliases and non typed constants.
This was newly added.
4. `Enum`: Use Pascal enumeration type for both C enums and bit fields.
This was newly added.
5. `Set`: Use Pascal enumeration type for both C enums and Pascal sets
for bit fields. This is now implemented.
These changes are:
1. Added line break to last line of generated files.
2. Removed unused field `FEnumImpl` from `TGirConsoleConverter`.
3. Moved command line from .lpi to .lps as this depends on the path
of the user debugging the program.
There was an issue with the logic for resolving opaque types that misses
some types due to not comparing C types with opaque type name.
This is now fixed and all Gtk3 units now compile without any manual
modification.
Tested with
43cac7495f
using
`./gir2pas/gir2pas -i gir-rs-files/Gtk-3.0.gir -o gtk3-test-enums -e Enum`
The generated code was missing an identifier and thus was unable to
compile.
Now we generated a name based on the type and this seems for fix the
issues with Gtk3.gir file.
If the type is not used within the unit it was declared in, then pointer
types will not generated. This causes an error when a pointer type is
used by a unit using it.
An example is a compilation error on `Pango1` that uses `Glib2` because
the type `Pgconstpointer` was not defined.
The new code generates a lost of pointer types, but at least it allows
get a code that compiles fine.
This section is placed just after the constants section in order to
avoid declaration of function parameters and variables of enumeration
types that are not yet declared.
The issue was hidden in the typed constants implementation because the
constants section is placed at the beginning of the unit. This is not
true anymore and thus we need a dedicated section.
Inserting `external` directive for `C` identifiers was done manually.
This commit adds a method to add such a directive for any identifier.
This helps keeping inserted code consistent and if a change is to be
done in the future, we do it at one place only.
Compilation directive `MsWindows`is inserted in 3 different places with
3 different case mixing.
Also white spaces around it are some times added and sometimes not.
This commit fixes all to a single convention.
Added a new command line option (CLO) `-e/--declare-enums-as` that
selects the way how to define C enums and bit fields.
Added support for 4 options and a 5th to be implemented later.
1. `IntConst`: No type, just use integer non typed constants. This was
already implemented, but not easily selected at CLI.
2. `TypedIntConst`: Use non strict type aliases and typed constants.
This was already implemented, selected by default in the code.
3. `IntAliasConst`: Use strict type aliases and non typed constants.
This was newly added.
4. `Enum`: Use Pascal enumeration type for both C enums and bit fields.
This was newly added.
5. `Set`: Use Pascal enumeration type for both C enums and Pascal sets
for bit fields. This is not yet added.
As the directories search list is not sorted, FPC implementation of
`TStringList` ignores the `dupIgnore` option and thus leads to having
the same entry multiple times in the list.
We forbid this manually in order to avoid searching multiple times for
the same file in the very same directory.
We also add more default search paths (Debian based).
The order of folders where to search for included files should be
related to user preference as follows:
1. directory where the input is located,
2. directories supplied by user at command line in the order they were
passed,
3. default system directories, where distributions used to put them.
This way, user can easily override files in the default system
directories without the need to have write access to such folder, as in
most Unix systems this will require root access.
Also, one expects, that if copy of an included file is placed in the
same directory as the input one, then this copy should be used.
This makes sens, because people generally work on the same directory,
and will consider their local work copy the preferred one to be used.
