parson
parson copied to clipboard
kgabis
Make build
A simple build & install task, to create a shared library, so it's not necessary to always include the Parson source, and possible to link against it.
make build sudo make install make clean
and then...
gcc my_source.c -l parson
I cannot merge it right now, because make install doesn't work on macOS. Any idea how to make it work on different operating systems?
Do you have any error messages for Mac OS? Perhaps you can change LIB_DIR=/lib to /usr/lib? This is speculation, I do not have a Mac.
/lib is for system libraries, not for general purpose ones. General purpose libraries are supposed to go under /usr/lib. Also, .so files on mac won't work, you need to compile it with gcc -dynamiclib parson.c -o libparson.dylib. So I suggest relying on the travis testing I opened another PR for in order to merge that PR. As a side note, I have another PR in the works for this feature (where I did different rules for the .o and the .so files, and also added some rule for the .a file, in order to provide an object suitable for static linking), so either I will open a PR to correct that one after it is merged, or I will submit my PR directly if my travis PR is merged, and you then can choose what you merge in.
and also added some rule for the .a file
To be honest: what's the point of creating an archive for single object file?
@mbelicki
what's the point
7heo commented
in order to provide an object suitable for static linking
I personally do never link against .o objects when they are supposed to be (part of) a library. I always create an .a object: it is easier to link, you do not need the object in the same directory, as you can use -L and -l. And the difference in size is negligible.
Ahhh... you want to install it and link it using -l flag. Then yes, generating archive is a good idea.
Sorry, it should be clear from the context. I probably missed it since for me installing parson seems to be rather inconvenient for normal usage.
@mbelicki The use case I would have in mind would be to use the parson repository as a git submodule in your project, and then build the .a in parson from your project's Makefile; and finally use -static -Lparson -lparson from your Makefile at link time.
Then $BIN_DIR/parson.o seems to be far more straight forward than -static -Lparson -lparson.
That's a religious opinion. To each their own. Both solutions work, and yours is causing slightly less overhead. Mine is more flexible, as you can install the library on your system as the result of make install, to be used as a static library on all your projects (without the -Lparson in your Makefiles obviously).
It's not a religious opinion. It's a fact. Feeding linker a path to another object just appends an object to collection of objects that linker has to link. The operation you propose involves understanding of three linker flags, which (1) tell it to prefer static linking, (2) add new search directory, (3) search among all potential library location to find one of possible names derived from -lparson. Clearly it is more complex behavior.
This complexity obviously brings the flexibility that you mention.
We're not discussing the same thing. I think it's safe to stop the noise here.