Cross-platform open-source make system ()

headers Jacob Foshee | 1 Nov 2006 01:41

_______________________________________________
CMake mailing list
CMake@...
http://www.cmake.org/mailman/listinfo/cmake
Hello 

I would like to discuss three points

1. naming conventions
2. what if pkg-config sends an error
3. protect already defined variables

------------------------------------

1. naming conventions:

The interface will get a prefix like
        pkg_check_modules(LIBNAME ...)

I would prefer to stick close to the command names, so

since INCLUDE_DIRECTORIES -> LIBNAME_INCLUDE_DIRECTORIES
since LINK_DIRECTORIES -> LIBNAME_LINK_DIRECTORIES
since LINK_LIBRARIES / TARGET_LINK_LIBRARIES -> LIBNAME_LINK_LIBRARIES
since ADD_DEFINITIONS -> LIBNAME_DEFINITIONS

rather than 
LIBNAME_INCLUDE_DIRS and
LIBNAME_LINK_LIBS ...

----------------------------------
2. what if the lib isn't found

This regards the pkg_check_modules interface. If the lib(s)
wasn't/weren't found or version(s) to low the developer should be able
to react.

IMHO there are two possible solution

first:
pkg_config(MYPREFIX found "lib1 >= ??? lib2 >= ??? ...")
if(NOT found)
	# FATAL_ERROR of looking for alternatives ...
endif(NOT found)

second:
pkg_config(MYPREFIX "lib1 >= ??? lib2 >= ??? ...")
if(NOT MYPREFIX_FOUND)
	# FATAL_ERROR of looking for alternatives ...
endif(NOT MYPREFIX_FOUND)

What do you're like more?

----------------------------------
3. protect already defined variables
How can we ensure that variables of the module-user won't be overwritten

Just a random example...

set(varname ...)
pkg_module_macro(...)
#...
# using varname

If inside the macro a
    SET(varname ...)
happens, the module user will be in trouble.

Is it possible to set variables being private?
If not, we can use a prefix like
    PKGCONFIG_PRIVATE_*
for all internal variables. For more complex tasks this may be a little
to verbose. So I played around doing something like this:

MACRO(...)   
 SET(PKGCONFIG_PRIVATE_list_of_used_vars 
            version_number_1_digits  
            version_number_2_digits
            version_number_1_digits_count
            version_number_2_digits_count
            to
            digit_is
            digit_min
            digits_count_min )  

PKGCONFIG_PRIVATE_VARS_SAVE(
PKGCONFIG_PRIVATE_list_of_already_used_vars
PKGCONFIG_PRIVATE_list_of_values_of_already_used_vars
${PKGCONFIG_PRIVATE_list_of_used_vars}
)
#

... do the work ....

#
PKGCONFIG_PRIVATE_VARS_RESTORE(
PKGCONFIG_PRIVATE_list_of_already_used_vars
PKGCONFIG_PRIVATE_list_of_values_of_already_used_vars
) 
ENDMACRO(...)

where the extra macros are

MACRO(PKGCONFIG_PRIVATE_VARS_SAVE  list_of_vars  list_of_var_values)

    FOREACH(item ${ARGN})
        IF(DEFINED ${item})
            LIST(APPEND ${list_of_vars} ${item})
            LIST(APPEND ${list_of_var_values} ${${item}} )
        ENDIF(DEFINED ${item})
    ENDFOREACH(item)

ENDMACRO(PKGCONFIG_PRIVATE_VARS_SAVE)

MACRO(PKGCONFIG_PRIVATE_VARS_RESTORE  list_of_vars  list_of_var_values)

    LIST(LENGTH ${list_of_vars} PKGCONFIG_PRIVATE_VAR_1 )
    LIST(LENGTH ${list_of_var_values} PKGCONFIG_PRIVATE_VAR_2 )
    IF(NOT ${PKGCONFIG_PRIVATE_VAR_1} EQUAL ${PKGCONFIG_PRIVATE_VAR_2} )
        MESSAGE(FATAL_ERROR "PKGCONFIG_PRIVATE_VARS_RESTORE: lists got
different length" )
    ENDIF(NOT ${PKGCONFIG_PRIVATE_VAR_1} EQUAL
${PKGCONFIG_PRIVATE_VAR_2} )    
    MATH(EXPR PKGCONFIG_PRIVATE_VAR_1 "${PKGCONFIG_PRIVATE_VAR_1} - 1")

    FOREACH(index RANGE ${PKGCONFIG_PRIVATE_VAR_1} )
        LIST(GET ${list_of_vars} ${index}  PKGCONFIG_PRIVATE_VAR_1 )
        LIST(GET ${list_of_var_values} ${index}
PKGCONFIG_PRIVATE_VAR_2 )  
        set(${PKGCONFIG_PRIVATE_VAR_1} ${PKGCONFIG_PRIVATE_VAR_2})   
    ENDFOREACH(index)

ENDMACRO(PKGCONFIG_PRIVATE_VARS_RESTORE)

----------------------------------

please spend your 2cents

Regards, Maik

Maik Beckmann wrote:
> Hello 
> 
> I would like to discuss three points
> 
> 1. naming conventions
> 2. what if pkg-config sends an error
> 3. protect already defined variables

Another approach to this problem is to setup the pkgconfig macros so
they can be used by Find*.cmake modules.  When a user wants to find
package Foo it should not matter how it is found.  The user should be
able to write

FIND_PACKAGE(FOO)

and get FOO_FOUND, FOO_INCLUDE_DIRS, etc. without knowing that it was
found via pkgconfig.  I'm not asking you to rewrite all our find modules
with your macros, but just to think about how the macros might be used
in the modules in the future.

> ------------------------------------
> 
> 1. naming conventions:
> 
> The interface will get a prefix like
>         pkg_check_modules(LIBNAME ...)
> 
> I would prefer to stick close to the command names, so
> 
> since INCLUDE_DIRECTORIES -> LIBNAME_INCLUDE_DIRECTORIES
> since LINK_DIRECTORIES -> LIBNAME_LINK_DIRECTORIES
> since LINK_LIBRARIES / TARGET_LINK_LIBRARIES -> LIBNAME_LINK_LIBRARIES
> since ADD_DEFINITIONS -> LIBNAME_DEFINITIONS
> 
> rather than 
> LIBNAME_INCLUDE_DIRS and
> LIBNAME_LINK_LIBS ...

The conventions used by other Find* modules are documented in the source
tree under CMake/Modules/readme.txt.

> ----------------------------------
> 2. what if the lib isn't found
> 
> This regards the pkg_check_modules interface. If the lib(s)
> wasn't/weren't found or version(s) to low the developer should be able
> to react.
> 
> IMHO there are two possible solution
> 
> first:
> pkg_config(MYPREFIX found "lib1 >= ??? lib2 >= ??? ...")
> if(NOT found)
> 	# FATAL_ERROR of looking for alternatives ...
> endif(NOT found)
> 
> second:
> pkg_config(MYPREFIX "lib1 >= ??? lib2 >= ??? ...")
> if(NOT MYPREFIX_FOUND)
> 	# FATAL_ERROR of looking for alternatives ...
> endif(NOT MYPREFIX_FOUND)
> 
> What do you're like more?

MYPREFIX_FOUND would be consistent with all the other Find* modules.

> ----------------------------------
> 3. protect already defined variables
> How can we ensure that variables of the module-user won't be overwritten
> 
> Just a random example...
> 
> set(varname ...)
> pkg_module_macro(...)
> #...
> # using varname
> 
> If inside the macro a
>     SET(varname ...)
> happens, the module user will be in trouble.
> 
> Is it possible to set variables being private?
> If not, we can use a prefix like
>     PKGCONFIG_PRIVATE_*
> for all internal variables. For more complex tasks this may be a little
> to verbose. So I played around doing something like this:
> 
> MACRO(...)   
>  SET(PKGCONFIG_PRIVATE_list_of_used_vars 
>             version_number_1_digits  
>             version_number_2_digits
>             version_number_1_digits_count
>             version_number_2_digits_count
>             to
>             digit_is
>             digit_min
>             digits_count_min )  

This is not necessary.  Just using the private prefix is good enough.
If PKGCONFIG_PRIVATE is too verbose just use "_" as a prefix.  This
convention has been followed by some other macro authors.

-Brad

Jacob Foshee wrote:
> Perhaps if Find<3rdParty>.cmake or <3rdParty>Config.cmake advertised a
> 3rdParty_BIN_DIR or 3rdParty_RUNTIME_DIR this would help?  I could try
> writing a FIND_RUNTIME_LIBRARY macro if that would help.

Some project's modules already do export a FOO_RUNTIME_LIBRARY_DIRS
variable (VTK at www.vtk.org for example).  It contains the list of
directories that should be included in the runtime library search path
when the project runs.  This should be used for PATH on windows and
LD_LIBRARY_PATH on unix.  Unfortunately we do not have time to sweep
through all the Find* modules to add this variable.  I'll add it to the
Modules/readme.txt in the source tree though so that new module authors
think about whether they need the variable.

-Brad

Maik Beckmann <maikbeckmann@...> writes:

> The interface will get a prefix like
>         pkg_check_modules(LIBNAME ...)
>
> I would prefer to stick close to the command names, so
>
> since INCLUDE_DIRECTORIES -> LIBNAME_INCLUDE_DIRECTORIES
> since LINK_DIRECTORIES -> LIBNAME_LINK_DIRECTORIES
> since LINK_LIBRARIES / TARGET_LINK_LIBRARIES -> LIBNAME_LINK_LIBRARIES
> since ADD_DEFINITIONS -> LIBNAME_DEFINITIONS
>
> rather than 
> LIBNAME_INCLUDE_DIRS and
> LIBNAME_LINK_LIBS ...

afais, the latter naming convention is required by Modules/readme.txt

> 2. what if the lib isn't found
>
> This regards the pkg_check_modules interface. If the lib(s) wasn't/weren't
> found or version(s) to low the developer should be able to react.

My module:

* sets <PREFIX>_FOUND iff pkgconfig succeeded
* bails out with a (more or less ugly[1]) error message when the REQUIRED
  keyword was used

> first:
> pkg_config(MYPREFIX found "lib1 >= ??? lib2 >= ??? ...")
> if(NOT found)
> 	# FATAL_ERROR of looking for alternatives ...
> ...
> if(NOT MYPREFIX_FOUND)
> 	# FATAL_ERROR of looking for alternatives ...

I think, both are possible at the same time. But by implementing the
first variant you will run into the used-variables problem ('found'
might be used by the local CMakeLists.txt already).

> 3. protect already defined variables
> How can we ensure that variables of the module-user won't be overwritten

This is probably a common cmake problem. I could not find a clear
description how variables are scoped in cmake.

As a general rule, I use:

* macro arguments and FOREACH(...) iterators can be short names because
  they are substituted as-is.
* variables which are modified by SET(...) in a module and will not be
  exported must have a long and ugly name, composed e.g. by an underscore
  and the module/function name.

> MACRO(...)   
>  SET(PKGCONFIG_PRIVATE_list_of_used_vars 

good idea; but how do you protect the global
'PKGCONFIG_PRIVATE_list_of_used_vars' variable?

Enrico

Footnotes: 
[1]  probably a cmake 2.4.3 bug because valgrind complains heavily. Did
     not tested with 2.4.4 yet

Orion Poplawski wrote:
> This is apparently because when the suffixes are added
> to the search list in cmFindBase they are checked for existence before
> the lib->lib64 mapping is done and since /usr/lib/octave-2.9.9 doesn't
> exist, it doesn't add it to the search.  I'd vote for just removing the
> existence check.  There's lots on non-existent directory searches
> already.  What's a few more?

Yes, please report this to the bug tracker.  I don't think it's there.

>   Is there any way to do a text search of issues in the bug tracker? I'd
> add this to it if I could check to see that it wasn't reported before.

On the "Query Bugs" page look at the bottom for an advanced query link.

-Brad

> rather than 
> > LIBNAME_INCLUDE_DIRS and
> > LIBNAME_LINK_LIBS ...
> 
> afais, the latter naming convention is required by Modules/readme.txt

Oh, didn't know. 

> first:
> > pkg_config(MYPREFIX found "lib1 >= ??? lib2 >= ??? ...")
> > if(NOT found)
> > 	# FATAL_ERROR of looking for alternatives ...
> > ...
> > if(NOT MYPREFIX_FOUND)
> > 	# FATAL_ERROR of looking for alternatives ...
> 
> I think, both are possible at the same time. But by implementing the
> first variant you will run into the used-variables problem ('found'
> might be used by the local CMakeLists.txt already).

"found" is provided by the user at the local CMakeLists.txt.
There is no need to check it to be used already, since a pkg_check_modules will use it by
   set( ${pkg_check_modules_name_for_the_second_argument} 1) 

> good idea; but how do you protect the global
> 'PKGCONFIG_PRIVATE_list_of_used_vars' variable?

I can't. It has to be mentioned in the module docs that the
PKGCONFIG_PRIVATE or whatever prefix must not be used!

My approach is for making it save to use short variable names like
"from" or "to".

Brad mentioned using "_" as a prefix should be enough. But what about
module authors who uses other modules? The modules may  "_"-prefix the
same variable name, i.e. "_to".

> Maik Beckmann wrote:
> > Hello 
> > 
> > I would like to discuss three points
> > 
> > 1. naming conventions
> > 2. what if pkg-config sends an error
> > 3. protect already defined variables
> 
> Another approach to this problem is to setup the pkgconfig macros so
> they can be used by Find*.cmake modules.  When a user wants to find
> package Foo it should not matter how it is found.  The user should be
> able to write
> 
> FIND_PACKAGE(FOO)
> 
> and get FOO_FOUND, FOO_INCLUDE_DIRS, etc. without knowing that it was
> found via pkgconfig.  I'm not asking you to rewrite all our find modules
> with your macros, but just to think about how the macros might be used
> in the modules in the future.
> 
> > ------------------------------------
> > 
> > 1. naming conventions:
> > ...
> The conventions used by other Find* modules are documented in the source
> tree under CMake/Modules/readme.txt.

Thanks, I didn't know.

> > ----------------------------------
> > 2. what if the lib isn't found
> > 
> > This regards the pkg_check_modules interface. If the lib(s)
> > wasn't/weren't found or version(s) to low the developer should be able
> > to react.
> > 
> > IMHO there are two possible solution
> > 
> > first:
> > pkg_config(MYPREFIX found "lib1 >= ??? lib2 >= ??? ...")
> > if(NOT found)
> > 	# FATAL_ERROR of looking for alternatives ...
> > endif(NOT found)
> > 
> > second:
> > pkg_config(MYPREFIX "lib1 >= ??? lib2 >= ??? ...")
> > if(NOT MYPREFIX_FOUND)
> > 	# FATAL_ERROR of looking for alternatives ...
> > endif(NOT MYPREFIX_FOUND)
> > 
> > What do you're like more?
> 
> MYPREFIX_FOUND would be consistent with all the other Find* modules.

Okay, so we should stick with this.

> > ----------------------------------
> > 3. protect already defined variables
> > How can we ensure that variables of the module-user won't be overwritten
> >  ...
> This is not necessary.  Just using the private prefix is good enough.
> If PKGCONFIG_PRIVATE is too verbose just use "_" as a prefix.  This
> convention has been followed by some other macro authors.

What about module authors who uses other modules? The modules may
"_"-prefix the same variable name, i.e. "_to".

> -Brad

Thanks for this wonderful tool!

Maik

Maik Beckmann wrote:
> Brad mentioned using "_" as a prefix should be enough. But what about
> module authors who uses other modules? The modules may  "_"-prefix the
> same variable name, i.e. "_to".

In that case you should just use the verbose prefix.  This is why we
call them MACROs and not functions.

-Brad

Hi,

will these presentations be available online or only for the participants
of the Vis06?

Regards, M.B.

Berk Geveci schrieb:

> Hello Everyone,
>
> Kitware will be hosting a VTK / ParaView / ITK "Birds-Of-A-Feather" (BOF)
> meeting in Baltimore, Maryland as part of the Visualization '06
> conference. This will take place on Thursday November 2, from
> 7pm to 9pm. There will be several short presentations on the current
> developments and the roadmap of VTK, ParaView and ITK.
>

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30

211	May 2013
426	April 2013
425	March 2013
356	February 2013
312	January 2013
197	December 2012
288	November 2012
349	October 2012
394	September 2012
409	August 2012
331	July 2012
531	June 2012
455	May 2012
316	April 2012
385	March 2012
459	February 2012
579	January 2012
489	December 2011
721	November 2011
583	October 2011
452	September 2011
405	August 2011
428	July 2011
584	June 2011
496	May 2011
424	April 2011
581	March 2011
694	February 2011
745	January 2011
529	December 2010
591	November 2010
579	October 2010
642	September 2010
613	August 2010
797	July 2010
586	June 2010
542	May 2010
457	April 2010
747	March 2010
544	February 2010
640	January 2010
651	December 2009
644	November 2009
600	October 2009
648	September 2009
591	August 2009
563	July 2009
739	June 2009
618	May 2009
732	April 2009
978	March 2009
620	February 2009
516	January 2009
575	December 2008
696	November 2008
584	October 2008
632	September 2008
576	August 2008
647	July 2008
451	June 2008
705	May 2008
538	April 2008
671	March 2008
620	February 2008
665	January 2008
789	December 2007
824	November 2007
639	October 2007
552	September 2007
579	August 2007
610	July 2007
525	June 2007
536	May 2007
370	April 2007
411	March 2007
267	February 2007
363	January 2007
293	December 2006
355	November 2006
416	October 2006
423	September 2006
512	August 2006
484	July 2006
513	June 2006
400	May 2006
243	April 2006
307	March 2006
330	February 2006
270	January 2006

Re: DLL not found question

Re: [ANN] New PkgConfig module

Re: [ANN] New PkgConfig module

Re: DLL not found question

Re: [ANN] New PkgConfig module

Re: PATH_SUFFIXES doesn't work on x86_64

Re: Re: [ANN] New PkgConfig module

Re: [ANN] New PkgConfig module

Re: Re: [ANN] New PkgConfig module

Re: [vtkusers] VTK/ParaView/ITK BOF at Vis06