[CMake] Shared library for a executable

[Raymond Wan]

Hi Tamás,


On Mon, Jan 25, 2016 at 7:02 PM, Tamás Kenéz <tamas.kenez at gmail.com> wrote:
> Gonzalo, Ray,
>
> I think your approaches are not in accordance with some CMake best practices
> (or at least what I believe they are).


Thank you for looking over my web site!  I welcome comments since I am
learning as I go along and I also don't know what "CMake best
practices" are.  There seems to be a lot of flexibility and a lot of
ways to get things wrong.


> Please take a look at Ray's example after a heavy refactor:
> https://github.com/tamaskenez/cmake-2016-jan-21-shared-lib-exe


Thanks for refactoring it!  I just realized I probably should have put
my example on GitHub.  Perhaps I'll do it instead of having just a
tar.gz file.


> These are the things I changed:
>
> - In your test executables don't compile the source files of the
> library-under-test into your test. Instead, link to the library. Reason (1)
> ODR, (2) this way you'll test the linking operation, too.


That's an excellent point!  Thanks!


> - Don't reach out from a subdirectory ('B') to include a sibling ('A'). It
> creates harmful coupling between the subdirectories. All information that
> 'B' needs to know about 'A' should be concentrated in the properties of the
> target 'A'. So you need to use commands like target_include_directories().
> - Unnecessary verbosity makes it harder to read and debug the CMakeLists.


The verbosity was a bit on purpose.  To help others follow the example
and to help me follow months after I look at it!  But, another reason
is that I have many CMakeLists.txt that are very similar.  And the
only part that is different are the filenames.  So, I do copy and
paste my CMakeLists.txt and change just all the filenames in one
place.

Perhaps it is hard to read and debug, but when almost all of my
CMakeLists.txt are the same, then it is actually a bit easier.


> - you can build and test 'A' standalone
> - you can build and test 'A', 'B' and 'X' in one project using the top-level
> CMakeLists.txt
> - you can't build 'B' standalone or can't build 'X' without 'A' and 'B'
> being there. If you need that feature, we need to add an install step to 'A'
> and 'B' and use find_package() in 'B' and 'X' on demand


Hmmmmm, I see.

However, the last point isn't what I was trying to achieve.  And I
mentioned it on the "Summary" page.

I was playing with this for a long time and did try what you suggest
above.  But, in one project, I had tree-like dependencies that
stretched for more than two levels.  (i.e., it wasn't just X needed A,
X needed B, X needed C, etc.).  So, I could have installed them into
the system, but I only needed it to compile X and cluttering a user's
system with libraries didn't seem like a good idea.

BUT, I now see a way around it.  I suppose I can install them into an
install path within the build tree.  And apply find_package () to just
within the build tree.

That would satisfy all of these criteria:

1)  A and B are independent,
2)  B can be built stand-alone,
3)  A and B are installed within the build tree,
4)  A and B are to be found with find_package (), and
5)  Only X is installed in the system-level directory (since that is
the only program that a user should run).

I think this sounds fine...  I will give it a try.  Thank you for your comments!

Ray