I use Clion 2016.1. For example, I run such code in the directory ~/CLionProjects/Tutorial:
#include <stdio.h>
int main() {
char * string;
string = "Hello, everyone";
printf(string);
}
Why does Clion go for this code to this directory?:
/home/ken/.CLion2016.1/system/cmake/generated/Tutorial-9a39f70/9a39f70/Debug/Tutorial
Hello, everyone
Process finished with exit code 15
How to make the programs running in "normal" directory ~/CLionProjects/Tutorial?
UPD
I want to read a "data.csv" file locates in the current directory (where main.c is). But CLion looks for it in /home/ken/.CLion2016.1/system/cmake/generated/Tutorial-9a39f70/9a39f70/Debug/Tutorial. How to make that CLion looks for data.csv in ~/CLionProjects/Tutorial?
If you want to appear your binaries in a folder you've specified, you need to tell it CLion by adjusting your CMakeLists.txt like this:
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_SOURCE_DIR}/bin)
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${PROJECT_SOURCE_DIR}/lib)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${PROJECT_SOURCE_DIR}/lib)
Edit:
Somehow it seems that these options are not respected in the current version of CLion (2016.2). Therefore one might has to change the desired output directory via: Build, Execution, Deployment | CMake settings and set it there.
For CLion v2016.1 and earlier
To change build output path, open CLion Settings and go to Build, Execution, Deployment | CMake settings and set it there.
This is more an answer for the UPD question than the original. But the answers are related. .EXE is built into a folder that depends on the build options (debug, release, etc). An exe's default working directory is the folder where the exe is found. That is the folder where the program will look for data files, etc, unless you tell it to look elsewhere.
You can change the working directory for the exe with a runtime option. I made a YouTube tutorial for my COSC1030 (Beginning C++) students but the solution is the same for everyone: https://youtu.be/dTtZEAfh_LM
Related
I have a project written in C. Currently it's using UNIX makefiles to compile itself for Linux, but recently I've been looking into CMake, to be more portable.
The executable, when running, needs to access some asset files that are part of the project. When using makefiles, I would just compile the project with:
make prefix=/usr
make prefix=/usr install
So while the project is compiled, it knows that it will end up in /usr, and when running, it searching for its own project files there (in something like /usr/share/my-project/).
I created a very basic CMakeLists.txt, that compiles the .exe file, and installs it together with one other asset file in the install directory. I then run the following commands to create an NSIS installer for Windows:
cmake.exe --build --config Release .
cpack.exe
Which succesfully gives me the NSIS installer. When run, it shows the user a few steps, one of them is to decide where the project will be installed, which the user can modify.
So my question is, at that point the project has already been compiled, so how can I pass to my project its own install location, so it can access files included in the project? How do other projects do this? I couldn't find much information online about it, which makes me think I might be taking the wrong approach.
For anyone stuck in a similar problem, I found one solution.
Upon looking online, this seems to be something not recommended for Unix systems, and setting the install location during compilation is pretty standard.
For windows, however, I found the function GetModuleFileNameW (GetModuleFileNameW function (libloaderapi.h)).
It returns the path to the current executable (something like C:\Program Files\<my-app>\bin\my-app.exe). I've confirmed it returns the right path, even when I install the project on different directories. It returns the result using wchar_t, so unicode directories are also supported.
Here is a small example of how it can be used:
// to keep the example simple, this is assuming maximum 1000 characters in the path
wchar_t dynamicProjectLocationW[1000];
GetModuleFileNameW(NULL, dynamicProjectLocationW, 999);
dynamicProjectLocationW[999] = L'\0';
// given a path like "C:\X\Y\bin\myapp.exe" find the second to last slash
// so we can get the path "C:\X\Y\"
wchar_t *pointer = dynamicProjectLocationW;
wchar_t *secondToLastSlash = 0;
wchar_t *lastSlash = 0;
while (pointer[0] != L'\0') {
if (pointer[0] == L'\\') {
secondToLastSlash = lastSlash;
lastSlash = pointer;
}
pointer++;
}
// cut the path short, so we can use the project path to find other files
if (secondToLastSlash) {
secondToLastSlash++;
secondToLastSlash[0] = L'\0';
}
This is solving my problem for now, so I'll be using this until a better solution is found.
I have never used Codelite and am attempting to use it as apart of a requirement for "C Programming for Beginners" course on UDEMY.
I am using a Macbook PRO OS version 10.14.5 and Codelite version 14.0.0.
I have created a workspace called SampleApp and within lies a project called Sample with a src file and a main.c file.
The main. c file contains the following code:
#include <stdio.h>
int main()
{
printf("Hello, my name is Link\n");
return 0;
}
When I build the code I get the following output:
/bin/sh -c '/usr/bin/make -j8 -e -f Makefile'
====0 errors, 0 warnings====
Working directory is set to: /Users/link/Desktop/c_code/build-Debug/lib
Executing: open -n -a Terminal /tmp/codelite-exec.sh
Program exited
Unfortunately though, when my terminal pops up I get the following error message:
22:37:07-link#links-MacBook-Pro:~$ /tmp/codelite-exec.sh ; exit;
/tmp/codelite-exec.sh: line 3: cd: /Users/link/Desktop/c_code/build-Debug/lib: No such file or directory
Hit any key to continue...
I am unsure of how to debug this or get this program to run as it appears the target and or the executing directory is not set properly. Kindly advise, thank you.
** UPDATE **
There is no lib folder within /Users/link/Desktop/c_code/build-Debug/lib .. perhaps that's why the code in /tmp/codelite-exec.sh is not working.. Below shows /tmp/codelite-exec.sh - line 2 attempts to change directories to the lib folder and execute the Sample workspace but the lib file doesn't exist..
#!/bin/bash
command="/Users/link/Desktop/c_code/build-Debug/bin/Sample"
cd /Users/link/Desktop/c_code/build-Debug/lib && ${command}
echo Hit any key to continue...```
I've just run into the same problem trying to build a simple wxWidgets HelloWorld with CodeLite before I do anything serious with it. It turns out that this is caused by a default project setting. Open the settings (by right-clicking on your project and selecting settings at the bottom, in case you haven't found this yet). In the General page, find the Execution group and look for Working Directory. It defaults to "$(WorkspacePath)/build-$(WorkspaceConfiguration)/lib", which is pretty silly since that won't be created by default. I changed "/lib" to "/bin" and that error went away.
I recently started converting a game engine I wrote in Java (using lwjgl) to C/C++. I am using Qt Creator and CMake on Fedora 25 (I'm pretty sure this doesn't affect anything) to link all the directories, files, etc. GLFW is installed on my system, but I decided to use the source version, rather than the included version. I am using glad for my extension loader, and configured it following the tutorial on the GLFW website. I haven't gotten past the "Hello World" test because when I include the glad.h file in my main.c file, I get an error:
<glad/glad.h>: No such file or directory
What is equally strange is that I get this same error in the glad.c file, the one that was created using glad's own generator. My main.c file looks like this
#include <stdio.h>
#include <glad/glad.h>
#include <GLFW/glfw3.h>
int main(int argc, char *argv[])
{
printf("Kick Ass Game Engine");
return 0;
}
I have also tried using "glad.h: instead of <glad/glad.h> (I found that suggestion here). This did work for my main.c file, but I still have the same issue with the glad.c file, even after I edited it to reflect main.c.
My project directory looks like this:
- KAGE/
-> CMakeLists.txt
-> glad.c
-> glad.h
-> main.c
-> khplatform.h
-> KAGE/lib/
-> glad
-> glfw-3.2.1
As you can see, all of my .c and their header files are in one directory. The lib directory is where I keep glad and glfw. I just copied the files from the lib/glad directory to the main project one.
My CMake looks like this
project(KAGE)
cmake_minimum_required(VERSION 2.8)
aux_source_directory(. SRC_LIST)
add_executable(${PROJECT_NAME} ${SRC_LIST})
set(GLFW_BUILD_DOCS OFF CACHE BOOL "" FORCE)
set(GLFW_BUILD_TESTS OFF CACHE BOOL "" FORCE)
set(GLFW_BUILD_EXAMPLES OFF CACHE BOOL "" FORCE)
add_subdirectory(/home/brian/KAGE/lib/glfw-3.2.1)
find_package(OpenGL REQUIRED)
target_link_libraries(KAGE glfw)
I have tried searching around, but all of the issues people had where when trying to call libraries installed on the system. Mine are not installed. I have a separate directory (lib) where I keep everything I use. The only solution I found that came close to what I was looking for was the one about replacing <glad/glad.h> with "glad.h". As I said earlier, this did not work. The tutorial on GLFW's website does not offer any other information or troubleshooting.
Any help or suggestions is greatly appreciated. Thank you.
Seems glad.h is not in a directory called glad, so including it via glad/glad.h is just never going to work!
If you on linux one trick is make a softlink to . called glad and then you can have glad/glad/glad/glad/glad.h if you want it.
Better solution is to install stuff properly so files end up at their expected paths...
CMake doesn't include current directory by default. For enable this behavior you need to set CMAKE_INCLUDE_CURRENT_DIR variable:
set(CMAKE_INCLUDE_CURRENT_DIR ON)
After that for including the header your glad.c file may use
#include "glad.h"
Today I met the same problem and found this posting.
I use vcpkg to manage my pkg.
I can be sure that the path of the file is right，but it do not work.
And magically，when I delete #include <glad/glad.h> and reenter it，it works.
If glad folder is in the project root directory, means:
KAGE
glad
then the Cmakelist for glad:
# glad
set(GLAD_DIR "${LIB_DIR}glad")
add_library("glad" "${GLAD_DIR}/src/glad.c")
target_include_directories("glad" PRIVATE "${GLAD_DIR}/include")
target_include_directories(${PROJECT_NAME} PRIVATE "${GLAD_DIR}/include")
target_link_libraries(${PROJECT_NAME} "glad" "${CMAKE_DL_LIBS}")
if it's in a lib directory
KAGE
lib
glad
then change cmkaelist:
from set(GLAD_DIR "${LIB_DIR}glad") to set(GLAD_DIR "${LIB_DIR}lib/glad")
I once tried to compile a C program I made that was for a chess game (thanks to YouTube's Bluefever Software for the tutorial), but when I went to compile the program, I executed this line of code:
C:\TDM-GCC-64\>gcc Chess/chess.c Chess/init.c -o chess
The compiling worked (there were no syntax errors or anything), but when I got to my file directory, I saw this (circled in blue):
An unexpected application (but there were no viruses!):
How did this happen? It may had something to do with the line I was compiling, but what is the "intel" behind this?
It is normal for the compiler to generate an application!
What is surprising is the location for the executable, it should have been generated in the parent directory:
C:\TDM-GCC-64\> gcc Chess/chess.c Chess/init.c -o chess
The explanation is interesting:
You are using the Windows operating system, where the filenames are case insensitive.
You instructed gcc to generate the executable into chess, but this is the name of the Chess directory. In this case, gcc generates the executable in the named directory and gives it a name that is the basename of the first source file chess.c -> chess.
Furthermore, the application name really is chess.exe in Windows, but the default setting for the file manager is to not display file extensions. This is a very unfortunate choice. I suggest you change this setting in the Windows/File Explorer Options window to always show file extensions. This will allow you to distinguish chess.c, chess.exe and chess.h more easily.
You have a Makefile in the Chess directory, you should use the make command to build the executable:
C:\TDM-GCC-64\> make -C Chess
Or simply cd to the Chess subdirectory and type:
C:\TDM-GCC-64\Chess> make
That's the file you told the compiler to make.
The -o option to gcc is the output file. In this case, you told it to create an executable file named chess. And that's exactly what was created.
The compiler is automatically creating an executable file while compiling.
When I run simple printf command, I get the following errors:
First.c 1: Unable to open file stdio.h
First.c 2: Unable to create output file 'D:\TCC\First.obj'
Please let me know what I did wrong here.
Platform : Windows
IDE: Turbo C
Solution in Windows
check this link and below solution:
this solution copied form one of stackoverflow.com pages
Check if you have anything like those stdio.h file and other header files under INCLUDE folder and LIB folder. LIB contains some files. In my case, I had the same issue but both of these folder were blank.. good to know. Steps:
Press: ALT + O + D (i.e. press ATL (keep pressed) and then O english character) and then D).
You'll see a popup window.
This window will have values for INCLUDE and LIB directories. The by default value for these two boxes in the popup window are: Drive leter where you installed TC... i.e. C:\ or D:\ or whatever followed by the path for INCLUDE and LIB folder. So, in my case,
INCLUDE box was set to: "C:\TC\INCLUDE" and LIB directory value box was set to: "C:\TC\LIB" (without quotes). Steps to resolve:
Press ALT + C.
Set your current directory as C:\TC\BGI
Press ALT + O + D, and put ../INCLUDE and ../LIB in Include/Lib directory values.
and now... when you'll run your progress, you'll say thanks to me. I like the archduchess C fractal graphics that I'm running on DOS Turbo C right now. Lol.
Solution in Linux
(not in case of this question but commonly this method is one of useful methods)
may be you are in linux and you have some missing .h and other library files. do this if you are in linux (this command works only on debian based distributions of linux ):
sudo apt-get install build-essential
for the others like fedora you can use this equivalent:
# yum install make automake gcc gcc-c++ kernel-devel byacc
or try
# yum groupinstall ‘Development Tools’
# yum groupinstall ‘Development Libraries’
Solution under Windows
Turbo has strange shorthand rules for file and directory names.
For example:
The location of my Turbo:
C:\TC200
C:\TC200\INCLUDE
C:\TC200\LIB
C:\TC200\MYPROJECTS
My Turbo's Options->Directories settings:
Include directories: C:\TC200\INCLUDE
Library directories: C:\TC200\LIB
Output directory: C:\TC200\MYPROJECTS
Turbo C directory: C:\TC200
Note that the above highlight setting is wrong, the right way is C:\TC200\MYPROJ~1