I need to generate *.hie files for all of my Haskell module files in a project managed by Haskell Stack. I do this, by adding the -fwrite-ide-info compilation flag to stack.yaml in the following form:
ghc-options:
"$locals": -fwrite-ide-info
Let's say the project consists of one package with a library and an executable. A stripped down package.cabal would be
name: package
library
exposed-modules:
Package.Exposed.Module
ghc-options: -fwrite-ide-info
executable binary
main-is: Main.hs
ghc-options: -fwrite-ide-info
build-depends:
package
Then, I run stack build.
During the compilation, the *.hie files are generated in the .stack-work directory.
To be exact, respectively, the library and executable files are in
path/to/project/package/.stack-work/dist/x86_64-linux-tinfo6/Cabal-3.0.1.0/build/Package/...
path/to/project/package/.stack-work/dist/x86_64-linux-tinfo6/Cabal-3.0.1.0/build/binary/binary-tmp/...
I need the *.hie files in the actual source directories, and, low and behold, those *.hie files show up for the library, but not for the executable.
Now my question: How does Haskell Stack handle *.hie files. Are they handled in a special way, e.g., are they copied to the source files, where they can be found by programs making use of them (one such program that I want to use is weeder)? If not, I have no idea how those *.hie files showed up. Do you have any suggestions?
Thank you!
So, it seems that Haskell Stack does not copy/move hie files to the source folders. Maybe it did that at some point, because otherwise I have no idea how the files popped up there. After deletion of the hie files in the source folders, weeder actually uses the hie files in the .stack-work directories. I apologize for the confusion.
Related
Maybe this has been asked before but I could not find anything, that answers my question precisely.
I created a New arm cortex cmsis cpp project in eclipse. This gave me the default folder structure. I build the debug config and now have the generated makefiles in the debug folder. From here I can Do "make clean" and "make and everything compiles fine. The makefiles (including the sub mk files) were to static for my needs, so I changed them to be more generic (I only tell the make where the src folders are and it scans all the folders for c and cpp files and builds All the obj files and dependencies). I also took the makefile out of the debug folder and put it one level up into the project folder. So all together, I changed the location of the makefile and made it more dynamic. Now when I run "make", everything runs fine. Everything is compiled BUT the generated .elf and .bin have a different size, compared to files, that were created with the original files. I can See in the terminal that make creates the same files in the same order with the same flags. Everything is identical except that the location of the files now is in ./ instead of ../ How is this possible?
Most object files and binaries contain information about the location of the source files, so that the debugger can locate them. There may be other changes such as date and time stamps (although it's unlikely this will change the size of the output).
You can run something like strings myprog | sort on both old and new programs and see if the strings in your program are now different sizes.
After installing cmake-3.8.1-win64-x64 I got thisenter image description here
So what can I do with this? Thanks.
cmake-gui does not help you create cmake configuration files, it parses these files to generate and configure projects.
In your source code directory, you should have a CMakeLists.txt file which defines the rules for CMAKE to configure your problem. That directory should be entered into the first box.
Next, you get to decide where to build the binaries. We could do it in the source directory, but the generated artifacts could pollute what is already there. "Cleaning" the build by deleting all of those artifacts while keeping the original sources is tedious at best, so it's a good idea to make an empty directory and use that as your binaries path.
Once you have those fields entered, you should be able to "Generate" or "Configure" your project. If you need help creating a CMakeLists.txt file (that's really the complicated part), then check out their tutorial.
I am currently working on a program that will have to be able to read and save PNG files. I've decided to use libpng so I've downloaded it's source files. I unpacked them and here is where my problem started.
There are very many files in the unpacked folder and I don't know which of them I should compile to get proper.o files that I will be able to link to my program.
There are makefiles in the libpng "scripts" directory. Most of those contain a list of the files that need to be compiled (namely, all of png*.c in the main libpng directory except for pngtest.c).
You'll also need pnglibconf.h which you can create by copying scripts/pnglibconf.h_prebuilt.
I'm working on my first project using cmake, and for the most part it's been going well but I've run into one problem I can't figure out.
Let's say I have my CMakeLists.txt file located at ~/project/build. I would like for the output from cmake (not the binaries, but the makefile/configuration files) to be independent of where I run cmake from.
As an example, if my terminal is sitting in the ~/project/build directory, calling cmake ~/project/build creates the makefile and everything else within the ~/project/build directory. This is the behaviour that I'd like. If I call cmake ~/project/build from anywhere else, it creates the makefile and everything else in whatever directory the terminal called the program from.
Is it possible to force cmake to generate its makefile and associated files in the same folder as the CMakeLists.txt file? I've taken a look through the documentation and I've had no problems figuring out how to change binary output directories, but I can't really find any mention of what I'm trying to do.
I realize this is a pretty minor annoyance (it's not that hard to move into my build folder before building the project) but I'm just wondering if it's possible and if there's some reason it wouldn't be advised.
You have to use 2 commands for this
1) cmake -B "Dest path(Any path in which u want to generate the output files)" -H"Source path(root CMakeLists.txt path)"
2) cmake --build "Dest path"
This may be a no-brainer for longtime boost users, but I’m just getting into boost.
I built the full boost distribution and BCP to extract just the parts I need to put in my VisualStudio C++ project.
What I found is when I call bcp, it copies the source tree to the destination. It doesn’t copy the required compiled lib files though (for those modules that need it).
So when I build my project and include
#include "boost/program_options.hpp"
for example, I get a linker error:
*Error 1 error LNK1104: cannot open file 'libboost_program_options-vc100-mt-sgd-1_54.lib'*
So my question is this:
should BCP also copy over the compiled LIB files as necessary ?
or
is it standard procedure for users of BOOST to manually copy those complied library files themselves?
I recently started experimenting with BCP. It seems like any boost modules that require libraries will not be copied, but instead they need to be built using bjam.
For example, when you run bcp on your code it will output some 'INFO' statements like this:
INFO: tracking source dependencies of library date_time due to presence of BOOST_DATE_TIME_DECL...
INFO: tracking source dependencies of library smart_ptr due to presence of "void sp_scalar_constructor_hook...
Notice that in addition to the generated 'boost' folder containing a bunch of copied boost header files there will be a 'libs' folder along with Jam files (Jamroot, Jamfile.v2, etc).
I think you need to cd to the directories with the Jamfiles and use bjam to build the needed libraries.
Maybe this answer will help:
Building a subset of boost in windows