-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adaptation of pallene-tracer
directly in Pallene
#614
Changes from 2 commits
7bc5fe2
8d99ce3
bdfd1eb
890999b
a1b85e1
906f8b3
ec66bf2
ff1cdb0
a329f07
e524558
d1617da
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -18,6 +18,7 @@ local c_compiler = {} | |
|
||
local CC = os.getenv("CC") or "cc" | ||
local CFLAGS = os.getenv("CFLAGS") or "-O2" | ||
local SHLIBLOC = os.getenv("SHLIBLOC") or "/usr/local/lib" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Pallene is installed via Luarocks, which checks that ptracer is installed. If Luarocks only checks default installation locations, then there would be nothing to gain by adding this configuration flag. And if we do need a configure flag, we should follow whatever scheme Luarocks uses (presumably it would use a ptracer-specific variables instead of a global sharedlib variable). I think that for now we can just leave this out and assume people will install to default locations. We can add configuration later if it comes up. |
||
|
||
local function get_uname() | ||
local ok, err, uname = util.outputs_of_execute("uname -s") | ||
|
@@ -61,6 +62,8 @@ function c_compiler.compile_o_to_so(in_filename, out_filename) | |
CFLAGS_SHARED, | ||
"-o", util.shell_quote(out_filename), | ||
util.shell_quote(in_filename), | ||
"-lptracer", | ||
"-Wl,-rpath="..SHLIBLOC, | ||
}) | ||
end | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure we want to get rid of -Wpedantic? If I remember correctly, it's not just for C89. In this case it would know about c99 and warn about things that are not c99.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a long and complicated history behind it that I have been researching thyself for a while.
Generally, for some time being ISO was in charge of publishing C standards (Like C89, C90, C95 and C99). People easily mistakes ISO standards as pure C standards (they are not wrong tho). But there is a catch. When it is said ISO C, it literally means C89 standard initially developed by ISO. It's because C89 is said to be the most complete C standard ever developed and other C standards are just inherited C89 with some extra features minus some strictness. The C89 standard is also said to be ANSI C by historical mistake (don't quote me on that).
According to GCC manual,
-Wpedantic
will generate warnings as if you are usingC89
. So, using it besideC99
actually doesn't make all that sense instead of using-std=c89
or-pedantic
or-ansi
flags to fully adoptC89
. But with that being said as all the standards are sorta inheritance ofC89
, there are some flags we can use to take advantage of some features of C89 aka ISO C. One of the flags that I came across recently while patching DWL (DWM for Wayland) is-Wdeclaration-after-statement
which uses the ISO C suggestion for keeping all the local variable declaration at the top.For the record, using
gcc
:-std
defaults to latest GNU C standard equivalent of-std=gnu**
.-std=c**
to use any pure C standard.-pedantic
or-ansi
to use ISO C89, which is less robust way to define-std=c89
.-Wpedantic
to generate warnings as if we are usingISO C89
even tho we may have some standard defined. Using-Wpedantic
with-Werror
is lesser of a robust way of using-std=c89
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the GCC manual:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From Wikipedia:
ANSI C, ISO C, and Standard C are successive standards for the C programming language published by the American National Standards Institute (ANSI) and ISO/IEC JTC 1/SC 22/WG 14 of the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). Historically, the names referred specifically to the original and best-supported version of the standard (known as C89 or C90). Software developers writing in C are encouraged to conform to the standards, as doing so helps portability between compilers.
This is from GCC flags manual:
-Wpedantic
-pedantic
Issue all the warnings demanded by strict ISO C and ISO C++; diagnose all programs that use forbidden extensions, and some other programs that do not follow ISO C and ISO C++. This follows the version of the ISO C or C++ standard specified by any -std option used.
Actually to be honest I am confused right now. From my experience, while using
-Wpedantic
with-std=c11
I was getting warnings which was ofC89
standard as far as I can remember.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am bringing back
-Wpedantic
flag.Here is where I was wrong: ISO C used to be historically and strictly referred to
C89
. But now it is not. ISO C standard in this case is the standard you specify using-std=
.