My $GOPATH looks like this:
src/
mypkg/
source.go
config.txt
bin/
mypkg
pkg/
somestuff/
When I build my package with go install (that builds and places the executable in bin), I'd like config.txt to be copied in that folder together with the executable. Is there a way to do so?
Sorry if I didn't find a way that may look obvious to you, but I'm new to programming, especially to Go.
You can "pack" the static files (text, images etc.) by including it into a .go file (usually automatically generated) and then compiling it into the stand-alone binary. You can do it by using https://github.com/golang/tools/blob/master/godoc/static/makestatic.go or with https://github.com/jteeuwen/go-bindata. See http://blog.ralch.com/tutorial/golang-embedded-resources/ for more information and examples.
Related
I am trying to use GLScene (a third-party FireMonkey component for C++Builder and Delphi). I downloaded the zip, and in it, among other things, are .bpl files for use in C++Builder. When I try to install the package in my project (a C++Builder multi-device application) under Component > Install Packages... > Add, I get this error:
My directory structure:
The _Installation directory and the Readme's are not very helpful. I have tried the other .bpl files and also tried importing all of them at once, but the same error occurs. How do I fix this?
There are several problems.
The XE3 extension is suspicious. I just downloaded and unzipped the GLScene download. The .BPLs in the CBXE3 and CBXE4 seem to be compiled for XE3 and XE4 respectively. But packages are version-dependent.
You should recompile the sources (also included) for 10.2 Tokyo. Just copy the DelphiXE4 directory to a new directory, and load the .groupproj file or the single .dpk files into the IDE. You might want to change the suffixes (currently XE3) of the packages to, say, Tokyo, in the project options, to avoid DLL (or BPL) hell.Also take a look at the pictures in the _Installation directory for the other options that must be set. Note that your paths may differ, theirs are just an example.
The compiler needs to be able to find the .bpi and .lib etc. files in order to be able to link. Set the directories with those files in the project options, as shown in the _Installation pictures.
The newly compiled .bpl files should be compiled to a directory on the Windows path, so they can be found by the system at runtime. In their example setup, (and in the _Installation pictures) that is the shown C:\Library\GLScene path.
it is awkward, but until now i always copy the *.h and the *.c files to my projekts location. this is a mess and i want to change it!
i want to build my own c library and have a few questions about it.
where should i locate the *.h files?
should i copy them in the global /usr/include/ folder or should i create my own folder in $HOME (or anywhere else)?
where should i locate the *.a files and the *.o files and where the *.c files.
i am using debian and gcc. my c projects are in $HOME/dev/c/.
i would keep my lib-sources in $HOME/dev/c/lib (if this is the way you could recommend) and copy the *.o, *.a and *.h files to the location i am asking for.
how would you introduce the lib-location to the compiler? should i add it to the $PATH or should i introduce it in the makefiles of my projekt (like -L PATH/TO/LIBRARY -l LIBRARY).
do you have anny further tips and tricks for building a own library?
I would recommend putting the files somewhere in your $HOME directory. Let's say you've created a library called linluk and you want to keep that library under $HOME/dev/c/linluk. That would be your project root.
You'll want a sensible directory structure. My suggestion is to have a lib directory containing your library and an include directory with the header files.
$PROJECT_ROOT/
lib/
liblinluk.so
include/
linluk.h
src/
linluk.c
Makefile
Compiling: When you want to use this library in another project, you'd then add -I$PROJECT_ROOT/include to the compile line so that you could write #include <linluk.h> in the source files.
Linking: You would add -L$PROJECT_ROOT/lib -llinluk to the linker command line to pull in the compiled library at link time. Make sure your .so file has that lib prefix: it should be liblinluk.so, not linluk.so.
A src directory and Makefile are optional. The source code wouldn't be needed by users of the library, though it might be helpful to have it there in case someone wants to remake the .so file.
As I commented, you should try first to build and install from its source code several free software libraries, e.g. like libonion or gdbm or GNU readline etc (don't use any distribution package, but compile and install these from source code). This will teach you some good practice.
You probably want to install these libraries system-wide, not for your particular user. Then, assuming that your library is called foo (you need to give it some name!),
the header files *.h go into /usr/local/include/foo/
the shared objects (dynamic libraries) go into /usr/local/lib/libfoo.so (with perhaps some version numbering)
if relevant, static library go into /usr/local/lib/libfoo.a
You need to add once /usr/local/lib/ into /etc/ld.so.conf and run ldconfig(8)
and you usually don't want to copy any source file *.c or object file *.o
(except for homoiconic programs, bootstrapped compilers, Quine programs, generated C code, etc... See RefPerSys or Jacques Pitrat systems as an incomplete example of self generated C or C++). In some weird cases, you may want to copy such "source" or "generated C" code under /usr/src/.
Read Program Library HowTo (and later, Drepper's paper: How To Write Shared Libraries)
You could consider making your library known by pkg-config. Then install some foo.pc under /usr/local/lib/pkgconfig/
BTW, I strongly suggest you to publish your library as free software, perhaps on github or elsewhere. You'll get useful feedback and could get some help and some bug reports or enhancements.
You probably should use some builder like make and have an install target in your Makefile (hint: make it use the DESTDIR convention).
I have a C program that was handed down to me by a developer who left. I am trying to figure out exactly what he had goign on and get the software re-arranged into something more logical so I can build it easier. I am using CMake to build, whereas he was using Make.
There is one src/ folder that had several source files in it, and out of those, about 4 had main() methods. The files with the main() methods are in files that are named more as if they are utilities, or tools, or whatever. This kind of strikes me as odd, because he also had a lib folder, with some other things in it that were built and looked more like libraries. Should I split out those main methods into "driver" source files, and make the methods that are also defined in those files to be other libraries? If I do this, I know how to make CMake go look for a library and build and link it to the driver for execution.
If it is acceptable to build those "library" source files where they are, in the src folder, should I just set CMake up to build everything in that folder all at once, or should I create a directory structure for at least some logical separation?
Just as an idea, here is the current directory structure
project
.../src
......file1.c
......file2.c <-has a main() as well as other methods
......file3.c
......file4.c <- has a main() as well as other methods
......file5.c
.../lib
....../lib1
........./file1.c <-references top level include folder files
........./file2.c
....../lib2
........./file1.c <-refs top level and local include files
........./file2.c
........./file2.h
.../scripts
.../include
.
.
.
Any advice on best practices for restructuring this build or configuring it in CMake is appreciated.
It's never too late for an answer, so I'd propose:
project
.../CMakeLists.txt
include_directories(include/)
add_subdirectory(lib/lib1)
add_subdirectory(lib/lib2)
add_subdirectory(src/)
.../lib/lib1/CMakeLists.txt
add_library(lib1 file1.c file2.c)
.../src/CMakeLists.txt
add_executable(test1 test1.c test2.c)
target_link_libraries(test1 lib1)
Why does it work: include_directories are derived in sub-directories, all targets (and thus libraries) from add_subdirectory are exported throughout the whole project.
My project's directory structure is basically as follows:
root/src
root/assets
root/library
I currently have CMake set up to compile the source, compile the library, and then link them, by calling make from the root directory.
I then have to manually move the executable into the original assets directory to get it to run, since that's where it expects to be (and we want to test with our directory structure in assets as close to what we expect it to be when it's done).
So, is there any way to tell CMake to automatically stick the compiled binary in that directory, as well as copy the assets over? Since we're doing out of source builds, sticking the executable back into the original project source's assets folder seems odd.
In short, two questions: Is there any way to get CMake to copy assets as well as code, and is there any way to have it copy the generated executable to a specific location in the build tree?
Any help would be appreciated --- thank you!
Here's a simple example with a structure like yours:
root/src/main.cpp (only source file)
root/assets (where I want the executable to go)
Here's the cmake file:
PROJECT(HelloCMake)
SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${HelloCMake_SOURCE_DIR}/assets)
add_executable (HelloCMake src/main.cpp)
When I build against this using Visual Studio I get the output placed in root/assets/debug. I'd have to dig to figure out how to get rid of the extra configuration folder (debug). Not perfect, but hopefully that gets you on the right track.
Edit...Even better:
INSTALL(TARGETS HelloCMake DESTINATION ${HelloCMake_SOURCE_DIR}/assets)
I'm using QTCreator as a code editor for my C++ project, not using the real features of the qmake compilation process.
My project has several subdirectories, in all of which I ran qmake -project to create a duummy .pro file that simply lists the source and header files in the directory.
In my root folder, I simply created a "main.pro" file that includes all these "subdir/subdir.pro" files.
So it looks like this:
./
main.pro
subdir1/
/include
/src
subdir1.pro
subdir2/
/include
/src
subdir2.pro
Now my problem is, I use some files that have a special file extension (say, .ccp), which are actually some C code but are used in a different step of my compilation process.
They are naturally ignored by the qmake -project command and do not appear in my project.
I read here that I could use the qmake setting QMAKE_EXT_CPP to tell it to gather my files as a C-code file, but it doesn't seem to be working.
If I run qmake -query QMAKE_EXT_CPP, I get .cpp::.c::.ccp (which I set right before), but when running a new qmake, it doesn't take my .ccp files in account.
So, three questions:
Is it possible to make qmake take some special extensions as a C++ file, when building the .pro file?
If yes, is it correct to use the QMAKE_EXT_CPP setting?
If yes, what should be the syntax of the QMAKE_EXT_CPP setting? (mine inspired by this forum post, but it might be bogus).
You cannot change QMAKE_EXT_CPP with -project option. The list of cpp extensions used at this stage is hardcoded into qmake. However after initial creation of .pro file you can edit it to extend with support for other extensions:
in test.pro
QMAKE_EXT_CPP += .ccp
SOURCES += test.ccp
You have to add new files manually.