I would like to build a project always using the --pedantic flag. Right now I'm using the
stack build --pedantic
command. But I would like to use this flag always for this project (thus, not globally). Is there a way to configure this?
Currently, pedantic pretty much just means to build with --ghc-options "-Wall -Werror". So, in stack.yaml you can do that with:
ghc-options:
"*": -Wall -Werror
In the future, --pedantic may do more than that, see https://github.com/commercialhaskell/stack/issues/1323 and https://github.com/commercialhaskell/stack/issues/3166 . At that point it may become an option in stack.yaml configuration.
Related
Yesterday i was working on FreeBSD jails. According to the documentation, I ran command make buildworld and it compiled lots of files using cc.
In logs i saw something like:
cc ... -pipe ... file.c
Now I'm curious about -pipe flag. I also searched in manual page but did not find anything about this flag.
Do you know what this flag exactly does?
Assuming your cc is Clang, a detailed man page was added in later versions of Clang that are not available on your FreeBSD version. The -pipe is described as:
-pipe, --pipe
Use pipes between commands, when possible
See https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-pipe
I sent an Email to Salvatore Sanfilippo (author of Redis) and asked above question and he replied with:
Hello, it simply will use Unix pipes instead of files in order to
"chain" the different stages needed for the compilation process. When
-pipe is used, as GCC starts to emit the assembler code, the assembler
will start to read from the pipe and emit the machine code and so
forth. It should optimize compilation speed, but in practice it helps
very little AFAIK.
Thanks to him.
What is the correct way to specify x11 dependency in a homebrew formula?
The default superenv removes /opt/X11/lib from its arguments.
I am writing a formula for a package that I can build outside of homebrew with the usual configure, make install.
So I have this install function:
def install
ENV["PKG_CONFIG_PATH"] = "/usr/local/opt/qt/lib/pkgconfig"
# ENV["PATH"] = "/usr/local/bin:/usr/bin:/bin" <--- work around
Dir.chdir("codebase")
system "./configure", "--disable-dependency-tracking", "--prefix=#{prefix}"
system "make install"
end
The link phase that gets echoed shows
/bin/sh ../../../../libtool --tag=CXX --mode=link clang++ .... -I /opt/X11/include ..... -L/opt/X11/lib ...
But the link fails with
ld: library not found for -lX11
If I add this to the top of the class definition, the build is successful
env :std
Alternatively, I can set PATH inside the build function and the build succeeds.
This makes sense since within the context of brew install, /usr/local/Homebrew/Library/Homebrew/shims/super appears at the start of the PATH, and that directory has a clang++ which among other things strips /opt/X11 components out.
I assume there is a good reason for this behavior, and am curious what is the best way to specify that X11 library.
The easiest way to know how to do something in writing Hombrew formulas is to look at existing formulas. For your case you can look at MuPDF a lightweight PDF and XPS viewer depending on X11. In its formula you will find the solution:
depends_on :x11
Some background: I have a project based on ESP-IDF which has a complex builtin building system which you plug into with your own makefile (their documentation on using it).
This works fine (apart from occasional horrendous build times), but now I wanted to add a build target for unit tests for a component, which requires building this component against another project (the unit-test-app).
So, I need another build target that calls another make with another makefile and directory. Something like this works fine:
make -C $(path to unit-test-app) \
EXTRA_COMPONENT_DIRS=$(my component directory) \
TEST_COMPONENTS=$(my component name) \
ESPPORT=$(my serial port) \
-j clean app-flash monitor
But only if I execute it from bash. If I try to execute it from another makefile, it breaks either not finding some header files (the include path is different between the main and unit test project) or ignores the change of project (-C argument) and executes the main project build.
What I tried:
using $(MAKE), $(shell which $(MAKE)) and make in the custom target
using env -i $(shell which $(MAKE) ) -C ... with forwarding required environment arguments to the child make
using bash -l make -C ... and bash -c make -C ...
What works but is a dirty hack: using echo $(MAKE) -C ... in the make target and then running $(make tests) from the command line.
As far as I know, this is an issue of the parent makefile setting something up in the environment that I did not separate the child makefile from. What else can I do to separate these two?
UPDATE: I have created an example project that shows the issue more clearly, please look at the top Makefile of https://github.com/chanibal/esp-idf-template-with-unit-tests
I reproduced your situation as you are describing it and everything works fine, both if I call the inner make from bash or from the outer make.
So there is something you are not telling us that is causing the failure.
On the other hand, I feel there are several irrelevant details in your description.
So, I suggest you try to further isolate the problem, removing irrelevant stuff, and reproducing the problem only from the description in your question, and then when you are doing it you will probably find out what is breaking. If not, then post here the minimal setup with all the other details that are needed for the failure to occur.
By the way, what you are doing is not good practice, so maybe just avoiding it would solve your problems.
What I mean is, there is one case and one case only, where recursive make is good practice: make -C ${directory}
where in directory you have a completely self-contained build, not using anything from the outside.
It seems this is not the case for you, because you seem to be passing some outside location variables. This kind of recursive make is bad practice and should be avoided.
I want to use clang for cross compiling. I've found out that it seems very easy, I can specify architectures/includes etc. just as I invoke clang directly. However, I don't want to keep passing those flags, I'd rather compile clang so that it would have these by default. That is, when I invoke clang just as clang++ main.cpp I'd like it to become clang++ -i686-w64-mingw32 -target-isystem=/usr/some/path main.cpp etc, how can I do that?
You can use a response file to do this sort of thing, it's also how you'd avoid command lines that are too long for your OS.
Something like:
clang #target_cmds.inc -c foo.c
will likely work for you.
(In addition to the earlier comments of some build system hackery or an alias, you could also define clang as a wrapper script that you invoke that does the same thing, e.g.:
#!/bin/sh
clang -target i686-w64-mingw32 -target-isystem=/usr/some/path $#
Use a makefile instead. Or create an alias in your bashrc. Everything else are crude hacks which I wouldn't use.
I'm looking for a way to write the standard output of my nmake call to a specified file. I tried something like "nmake target > file.log", but this won't work. Moreover I call multiple nmakes from within my MAKEFILE and may use multiple log-files to keep track of the output. I've only found the nmake option to write errors to a file but what's about the standard output.
Is there a simple way to do that (in Windows)?
#Cheeso
I've tried to built simple example and noticed that it doesn't work for me because the MAKEFILE must running in elevated mode. Consider a makefile like this:
default:
REM Test
and a batch-file like this:
cd /d "%~dp0"
nmake output.log
pause
When running the batch-file as administrator it doesn't redirect the stdout to my file and returns an error.
jom is really picky, and it's made based on nmake. Since that's the case, we're probably dealing with the same pickiness.
This works : jom -j 8 >> build.log
While this doesn't work : jom -j 8>>build.log
Add some whitespace, and you should be good to go. This was incredibly annoying for me too with Qt 5.6.1-1. I even tried using Powershell transcripts, but that ended up being a complete bust.