[Chicken-users] Re: [CMake] liblib

[Brandon J. Van Every]

William A. Hoffman wrote:

At 02:23 PM 2/16/2006, Brandon J. Van Every wrote:

  

I have wondered if a global way to control this behavior for all libraries is a good idea.  I mean, most people don't really want to type stuff in for every single library they're building.  Of course you don't want a global behavior to be inescapable; people still have to be able to make local exceptions.
    

This issue usually comes up when moving a UNIX tool to windows.  
On UNIX all libraries are prefixed with lib, as this is required for
-l to find the library and things to work.  However, on windows,
no such prefix is required, and instead a suffix of .lib is used.
CMake keeps this hidden from the user, as they create a library with
a name, and it may or may not have lib added to the name depending on
the platform, but cmake will be able to use the library.   The problem
comes up when someone wants lib to be a prefix on windows.   For this case
you have to tell cmake to do something different or not the default.  In the
case of chicken it is because chicken dynamically loads a library called
libchicken, and that is hard coded, and does not change based on the platform.

So, I am not sure why you would want to add the prefix lib to all libraries
in a project....
  

All libraries IF(MSVC), or other non-GCC Windows compilers, or other platforms that don't have Unix -l behavior.  I don't want to type SET_TARGET_PROPERTIES(mylib PROPERTIES PREFIX "lib") for every single library.  Call me lazy.

I think CMake will gain more acceptance if it is less verbose, so long as shorter forms do not compromise the engineering robustness.  Sometimes they do; then it is better to make people spell things out the long way.  But I'm very conscious of the fact that the 1st time anyone looks at a CMakeLists.txt for any appreciable project, it looks like a pile of gobbledygook.  Straightforward gobbledygook if you're coming from a GNU Autoconf background, as I am, but a lot of people don't have any particular build background and their eyes just glaze over when confronted with it.  Anything that can put the syntax on a diet is desireable IMO, so long as it remains readable, clear, and doesn't compromise the engineering robustness.

A thought: is it possible to do type inference on SET_*_PROPERTIES, i.e. automagically determine whether something is a target, a file, or a test?  Then we wouldn't need 3 different SET_*_PROPERTIES functions.  We could just have 1, SET_PROPERTIES.

Also, SET_DIRECTORY_PROPERTIES(PROPERTIES blah blah blah) is redundant.  It could be just SET_DIRECTORY_PROPERTIES(blah blah blah).  On the other hand, you could just do SET_PROPERTIES and type infer the directories.  Then if people want the current directory, they would write SET_PROPERTIES(. PROPERTIES blah blah blah).


Cheers,
Brandon Van Every

 so that we don't need