Re: [Oorexx-devel] Any ideas how to fix bug 1645 ?

2019-08-13 Thread Enrico Sorichetti via Oorexx-devel
Hello Mark, Rony

IMO the logic to determine the installation directory structure is broken


Create a test directory with the following CMakeLists.txt

#[[ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
CMakeLists.txt
Copyright Enrico Sorichetti 2018 - 2019
Distributed under the Boost Software License, Version 1.0.
(See accompanying file BOOST_LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt)
#]]

#[[ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Specify that the current CMake code is written for the given
version of CMake.  All policies introduced in the specified
version or earlier will be set to use ``NEW`` behavior.
#]]
cmake_minimum_required( VERSION 3.14 )

#[[ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
dummy project
#]]
project( dummmy )

#[[ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
#]]
function( vsnap )

set( _args "${ARGV}" )
list( SORT _args )
list( REMOVE_DUPLICATES _args )

set( _selvars "" )

get_cmake_property( _allvars VARIABLES )

foreach( _argv IN LISTS _args )

string( REGEX MATCH "([^\\*]*)" _head "${_argv}" )

if( _head STREQUAL _argv )
list( APPEND _selvars "${_argv}" )
continue()
endif()

string (REGEX MATCHALL "(^|;)${_head}[A-Za-z0-9_]*" _vars "${_allvars}")

foreach( _var IN LISTS _vars )

if( "${_var}" STREQUAL "" )
continue()
endif()

list( APPEND _selvars "${_var}" )

endforeach()

endforeach()

list( SORT _selvars )

list( REMOVE_DUPLICATES _selvars )

foreach( _var IN LISTS _selvars )
message( "[[ ${_var} '${${_var}}' " )
endforeach()

return()

endfunction()

#[[ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
#]]
include( GNUInstallDirs )

vsnap( "CMAKE_INSTALL_*")


Running cmake it will show a GNU compliant install directory structure 

Tested on Fedora30 it returned 

[[ CMAKE_INSTALL_BINDIR 'bin' 
[[ CMAKE_INSTALL_DATADIR 'share' 
[[ CMAKE_INSTALL_DATAROOTDIR 'share' 
[[ CMAKE_INSTALL_DEFAULT_COMPONENT_NAME 'Unspecified' 
[[ CMAKE_INSTALL_DOCDIR 'share/doc/dummmy' 
[[ CMAKE_INSTALL_FULL_BINDIR '/usr/local/bin' 
[[ CMAKE_INSTALL_FULL_DATADIR '/usr/local/share' 
[[ CMAKE_INSTALL_FULL_DATAROOTDIR '/usr/local/share' 
[[ CMAKE_INSTALL_FULL_DOCDIR '/usr/local/share/doc/dummmy' 
[[ CMAKE_INSTALL_FULL_INCLUDEDIR '/usr/local/include' 
[[ CMAKE_INSTALL_FULL_INFODIR '/usr/local/share/info' 
[[ CMAKE_INSTALL_FULL_LIBDIR '/usr/local/lib64' 
[[ CMAKE_INSTALL_FULL_LIBEXECDIR '/usr/local/libexec' 
[[ CMAKE_INSTALL_FULL_LOCALEDIR '/usr/local/share/locale' 
[[ CMAKE_INSTALL_FULL_LOCALSTATEDIR '/usr/local/var' 
[[ CMAKE_INSTALL_FULL_MANDIR '/usr/local/share/man' 
[[ CMAKE_INSTALL_FULL_OLDINCLUDEDIR '/usr/include' 
[[ CMAKE_INSTALL_FULL_RUNSTATEDIR '/usr/local/var/run' 
[[ CMAKE_INSTALL_FULL_SBINDIR '/usr/local/sbin' 
[[ CMAKE_INSTALL_FULL_SHAREDSTATEDIR '/usr/local/com' 
[[ CMAKE_INSTALL_FULL_SYSCONFDIR '/usr/local/etc' 
[[ CMAKE_INSTALL_INCLUDEDIR 'include' 
[[ CMAKE_INSTALL_INFODIR 'share/info' 
[[ CMAKE_INSTALL_LIBDIR 'lib64' 
[[ CMAKE_INSTALL_LIBEXECDIR 'libexec' 
[[ CMAKE_INSTALL_LOCALEDIR 'share/locale' 
[[ CMAKE_INSTALL_LOCALSTATEDIR 'var' 
[[ CMAKE_INSTALL_MANDIR 'share/man' 
[[ CMAKE_INSTALL_OLDINCLUDEDIR '/usr/include' 
[[ CMAKE_INSTALL_PREFIX '/usr/local' 
[[ CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT '1' 
[[ CMAKE_INSTALL_RUNSTATEDIR 'var/run' 
[[ CMAKE_INSTALL_SBINDIR 'sbin' 
[[ CMAKE_INSTALL_SHAREDSTATEDIR 'com' 
[[ CMAKE_INSTALL_SO_NO_EXE '0' 
[[ CMAKE_INSTALL_SYSCONFDIR 'etc' 


Note how it correctly determined that the libraries should be installed into 
lib64

Cheers

Enrico

PS.
The changes to the ooRexx CMakeLists are minimal
The destination directories should be defined as variables properly 
initialised, rather than hardcoded


> On 14 Aug 2019, at 06:10, Mark Hessling  wrote:
> 
> Hi Rony,
> 
> I had the same issue when I made the changes to the CMake processing to build 
> the RPM.  To get the configurability of update-alternatives I had to use a 
> user-supplied spec file rather than the CMake-generated one. This appears to 
> have caused CMake to not understand where the generated RPM file is.  
> I updated my CMake to CMake v3 and didn't get the error, however this version 
> of CMake ignored the name of the RPM file and used its own name.
> 
> I don't know CMake enough to determine how to fix the build issue.
> Cheers, Mark
> On 13/8/19 10:53 pm, Rony G. Flatscher wrote:
>> Hi there,
>> 
>>  
>>  reports a problem when using 
>> CMake to create a rpm package for ooRexx on Linux (used to work) using the 
>> command "cpack ./" after successfully running "cmake -DBUILD_RPM=1 
>> -DOS_DIST=fedora 

Re: [Oorexx-devel] Any ideas how to fix bug 1645 ?

2019-08-13 Thread Mark Hessling
Hi Rony,

I had the same issue when I made the changes to the CMake processing to
build the RPM.  To get the configurability of update-alternatives I had
to use a user-supplied spec file rather than the CMake-generated one.
This appears to have caused CMake to not understand where the generated
RPM file is. 

I updated my CMake to CMake v3 and didn't get the error, however this
version of CMake ignored the name of the RPM file and used its own name.

I don't know CMake enough to determine how to fix the build issue.

Cheers, Mark

On 13/8/19 10:53 pm, Rony G. Flatscher wrote:
>
> Hi there,
>
>  reports a problem when
> using CMake to create a rpm package for ooRexx on Linux (used to work)
> using the command "cpack ./" after successfully running "cmake
> -DBUILD_RPM=1 -DOS_DIST=fedora -DCMAKE_BUILD_TYPE=Release
> path-2-oorexx-trunk" followed by "make".
>
> The reason seems that the "make" step creates the so-files in
>
>    
> "../_CPack_Packages/Linux/RPM/ooRexx-5.0.0-11902.fedora.x86_64/usr/*lib*/..."
>
>
> whereas cpack tries to copy from
>
>    
> "../_CPack_Packages/Linux/RPM/ooRexx-5.0.0-11902.fedora.x86_64/usr/*lib64*/..."
>
>
> which does not exist causing error messages and the abortion of the
> rpm building step.
>
> Any ideas how to fix this?
>
> TIA,
>
> ---rony
>
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

-- 

* Mark Hessling, m...@rexx.org http://www.rexx.org/
* Author of THE, a Free XEDIT/KEDIT editor and, Rexx/SQL, Rexx/CURL, etc.
* Maintainer of Regina Rexx interpreter
* Use Rexx? join the Rexx Language Association: http://www.rexxla.org/ 


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel


[Oorexx-devel] Any ideas how to fix bug 1645 ?

2019-08-13 Thread Rony G. Flatscher
Hi there,

 reports a problem when using 
CMake to create a rpm
package for ooRexx on Linux (used to work) using the command "cpack ./" after 
successfully running
"cmake -DBUILD_RPM=1 -DOS_DIST=fedora -DCMAKE_BUILD_TYPE=Release 
path-2-oorexx-trunk" followed by
"make".

The reason seems that the "make" step creates the so-files in

    
"../_CPack_Packages/Linux/RPM/ooRexx-5.0.0-11902.fedora.x86_64/usr/*lib*/..."

whereas cpack tries to copy from

    
"../_CPack_Packages/Linux/RPM/ooRexx-5.0.0-11902.fedora.x86_64/usr/*lib64*/..."

which does not exist causing error messages and the abortion of the rpm 
building step.

Any ideas how to fix this?

TIA,

---rony

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel