You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by Massimo Manghi <mx...@apache.org> on 2018/12/18 13:40:21 UTC

Rivet pkgIndex.tcl version numbers

Automake generated Makefile uses a clever way to generate the Rivet's 
packages index by running tclsh and pkg_mkIndex within the 'install' 
target of the Makefile. CMakeList.txt doesn't provide the same feature 
and in principle pure CMake builds, where version numbers change, end up 
installing a wrong pkgIndex.

We could probably agree on a different approach requiring the repository 
to always store a consistent pkgIndex.tcl file by moving the index 
generation in a specialized Makefile target (we do provide binary 
packages too whose version number is stored in rivet_config.h). This 
target could be run every time some version number (Rivet's own version 
number included) changes. I know it's not automatic, but it's not a 
frequent event either. I don't know if this target can be replicated in 
CMAke but it's probably useless to try to implement it provided we take 
care to keep pkgIndex.tcl consistent, no matter how it was generated.

  -- Massimo

---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org


Re: Rivet pkgIndex.tcl version numbers

Posted by Massimo MANGHI <ma...@unipr.it>.
On 12/19/18 1:20 PM, Georgios Petasis wrote:
> Why we need to guess? Aren't all extensions being ".so" for all platforms?

I'm not sure I understand. Windows creates .dll files and in fact 
without these lines

SET_TARGET_PROPERTIES(mod_rivet PROPERTIES PREFIX "" SUFFIX ".so")
...

mod_rivet too would end up having dll as extension. In 2017, when we 
worked on the Windows build, I changed it to be ".so" just for sake of 
uniformity with all the other module names shipped by the binary 
distribution of Apache. But maybe it's the guys at ApacheLounge who are 
pushing this choice too far. I don't know....

> In line 138 of CMakeLists.txt I see that I have put manually everything 
> to .so.
> 
> So, I will simply put .so also in the script.


that means that every [info sharedlibextension] should go and replaced 
with a literal ".so", hoping Windows oldtimers are not upset by this 
coup ;-)

  -- Massimo

Re: Rivet pkgIndex.tcl version numbers

Posted by Georgios Petasis <pe...@apache.org>.
Στις 19/12/2018 14:20, ο Georgios Petasis έγραψε:
> Στις 19/12/2018 14:03, ο Massimo Manghi έγραψε:
>> On 12/19/18 10:08 AM, Georgios Petasis wrote:
>>>
>>> Dear Massimo,
>>>
>>> I have committed an update to CMakeLists.txt (master branch), which:
>>> 1) After libs have been installed, writes a file 
>>> "regenerate_pkgIndex.tcl", inside the installation directory.
>>> 2) Puts in the file:
>>> "puts \"Regenerating pkgIndex.tcl in [pwd]:\"
>>> file delete {*}[glob [file join packages * pkgIndex.tcl]] pkgIndex.tcl
>>> pkg_mkIndex -verbose [pwd] init.tcl \\
>>>        {*}[glob [file join packages * *.tcl] \\
>>>        [file join ${RIVET_LIBS_ARCH} *[info sharedlibextension]]]"
>>
>> librivetparser and librivetlib are created with the .so suffix on 
>> Windows too so this code would fail to put these libraries in 
>> pkgIndex (see my notes below anyway). We must keep the module named 
>> as mod_rivet.so because Apache itself expects this suffix but we can 
>> adopt the OS native suffix for any other binary library.
>>
>> I guess this requires a similar procedure for the library suffix 
>> determination. I tried something like
>>
>> execute_process(COMMAND ${shell_command}
>>             ERROR_VARIABLE EXEC_ERROR_VAR
>>             OUTPUT_VARIABLE LIB_SUFFIX
>>             OUTPUT_STRIP_TRAILING_WHITESPACE)
>>
>>
>> where shell_command to is
>>
>> ${TCL_TCLSH} inlinetcl.tcl puts [info sharedlibextension]
>>
>> where inline.tcl simply is
>>
>> eval $argv
>>
>> it works from the command line, but execute_process returns empty 
>> output variables
> Why we need to guess? Aren't all extensions being ".so" for all 
> platforms?
> In line 138 of CMakeLists.txt I see that I have put manually 
> everything to .so.
>
> So, I will simply put .so also in the script.
>>
>>> 3) Executes the file with tclsh (it will break if tclsh is not found 
>>> during configuration)
>>> 4) Deletes the file.
>>>
>>> I have replaced "eval" with "{*}". Eval will break if paths contain 
>>> spaces (very common in Windows). "{*}" will break in old tcl 
>>> versions (I do not remember when it was introduced).
>>>
>>> *I do not know what it should be put in RIVET_LIBS_ARCH*.
>>>
>>
>> The way you defined RIVET_LIB_ARCH it points to the directory that 
>> keeps only the MPM bridges modules that must not go to pkgIndex as 
>> they are of no general usefulness. Their named is determined by this 
>> macro
>>
>> #define RIVET_MPM_BRIDGE_COMPOSE(bridge)
>> RIVET_DIR,"/mpm/rivet_",bridge,"_mpm.so"
>>
>> in RIVET_LIB_ARCH just remove the final 'mpm' and put the right 
>> suffix in the code fragment.
> Ok.
>
> George
>>
>> I'm in favor to adopt the native suffix for external libraries too, 
>> as libraries such as librivet are of generic purpose and they can be 
>> used from the shell
>>
>> -- Massimo 

I am confused. librivetparser and librivetlib are created with the *.dll 
*suffix on Windows.

However, I have committed a new CMakeLists.txt that I think works.
It seems that pkg_mkIndex wants patterns (relative to the dir given), 
and not full paths.
Thus, I got rid of all globs.

Best,

George


Re: Rivet pkgIndex.tcl version numbers

Posted by Georgios Petasis <pe...@apache.org>.
Στις 19/12/2018 14:03, ο Massimo Manghi έγραψε:
> On 12/19/18 10:08 AM, Georgios Petasis wrote:
>>
>> Dear Massimo,
>>
>> I have committed an update to CMakeLists.txt (master branch), which:
>> 1) After libs have been installed, writes a file 
>> "regenerate_pkgIndex.tcl", inside the installation directory.
>> 2) Puts in the file:
>> "puts \"Regenerating pkgIndex.tcl in [pwd]:\"
>> file delete {*}[glob [file join packages * pkgIndex.tcl]] pkgIndex.tcl
>> pkg_mkIndex -verbose [pwd] init.tcl \\
>>        {*}[glob [file join packages * *.tcl] \\
>>        [file join ${RIVET_LIBS_ARCH} *[info sharedlibextension]]]"
>
> librivetparser and librivetlib are created with the .so suffix on 
> Windows too so this code would fail to put these libraries in pkgIndex 
> (see my notes below anyway). We must keep the module named as 
> mod_rivet.so because Apache itself expects this suffix but we can 
> adopt the OS native suffix for any other binary library.
>
> I guess this requires a similar procedure for the library suffix 
> determination. I tried something like
>
> execute_process(COMMAND ${shell_command}
>             ERROR_VARIABLE EXEC_ERROR_VAR
>             OUTPUT_VARIABLE LIB_SUFFIX
>             OUTPUT_STRIP_TRAILING_WHITESPACE)
>
>
> where shell_command to is
>
> ${TCL_TCLSH} inlinetcl.tcl puts [info sharedlibextension]
>
> where inline.tcl simply is
>
> eval $argv
>
> it works from the command line, but execute_process returns empty 
> output variables
Why we need to guess? Aren't all extensions being ".so" for all platforms?
In line 138 of CMakeLists.txt I see that I have put manually everything 
to .so.

So, I will simply put .so also in the script.
>
>> 3) Executes the file with tclsh (it will break if tclsh is not found 
>> during configuration)
>> 4) Deletes the file.
>>
>> I have replaced "eval" with "{*}". Eval will break if paths contain 
>> spaces (very common in Windows). "{*}" will break in old tcl versions 
>> (I do not remember when it was introduced).
>>
>> *I do not know what it should be put in RIVET_LIBS_ARCH*.
>>
>
> The way you defined RIVET_LIB_ARCH it points to the directory that 
> keeps only the MPM bridges modules that must not go to pkgIndex as 
> they are of no general usefulness. Their named is determined by this 
> macro
>
> #define RIVET_MPM_BRIDGE_COMPOSE(bridge)
> RIVET_DIR,"/mpm/rivet_",bridge,"_mpm.so"
>
> in RIVET_LIB_ARCH just remove the final 'mpm' and put the right suffix 
> in the code fragment.
Ok.

George
>
> I'm in favor to adopt the native suffix for external libraries too, as 
> libraries such as librivet are of generic purpose and they can be used 
> from the shell
>
> -- Massimo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org


Re: Rivet pkgIndex.tcl version numbers

Posted by Massimo Manghi <mx...@apache.org>.
On 12/19/18 10:08 AM, Georgios Petasis wrote:
> 
> Dear Massimo,
> 
> I have committed an update to CMakeLists.txt (master branch), which:
> 1) After libs have been installed, writes a file 
> "regenerate_pkgIndex.tcl", inside the installation directory.
> 2) Puts in the file:
> "puts \"Regenerating pkgIndex.tcl in [pwd]:\"
> file delete {*}[glob [file join packages * pkgIndex.tcl]] pkgIndex.tcl
> pkg_mkIndex -verbose [pwd] init.tcl \\
>        {*}[glob [file join packages * *.tcl] \\
>        [file join ${RIVET_LIBS_ARCH} *[info sharedlibextension]]]"

librivetparser and librivetlib are created with the .so suffix on 
Windows too so this code would fail to put these libraries in pkgIndex 
(see my notes below anyway). We must keep the module named as 
mod_rivet.so because Apache itself expects this suffix but we can adopt 
the OS native suffix for any other binary library.

I guess this requires a similar procedure for the library suffix 
determination. I tried something like

execute_process(COMMAND ${shell_command}
			ERROR_VARIABLE EXEC_ERROR_VAR
			OUTPUT_VARIABLE LIB_SUFFIX
			OUTPUT_STRIP_TRAILING_WHITESPACE)


where shell_command to is

${TCL_TCLSH} inlinetcl.tcl puts [info sharedlibextension]

where inline.tcl simply is

eval $argv

it works from the command line, but execute_process returns empty output 
variables

> 3) Executes the file with tclsh (it will break if tclsh is not found 
> during configuration)
> 4) Deletes the file.
> 
> I have replaced "eval" with "{*}". Eval will break if paths contain 
> spaces (very common in Windows). "{*}" will break in old tcl versions (I 
> do not remember when it was introduced).
> 
> *I do not know what it should be put in RIVET_LIBS_ARCH*.
> 

The way you defined RIVET_LIB_ARCH it points to the directory that keeps 
only the MPM bridges modules that must not go to pkgIndex as they are of 
no general usefulness. Their named is determined by this macro

#define RIVET_MPM_BRIDGE_COMPOSE(bridge)
                              RIVET_DIR,"/mpm/rivet_",bridge,"_mpm.so"

in RIVET_LIB_ARCH just remove the final 'mpm' and put the right suffix 
in the code fragment.

I'm in favor to adopt the native suffix for external libraries too, as 
libraries such as librivet are of generic purpose and they can be used 
from the shell

-- Massimo

---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org


Re: Rivet pkgIndex.tcl version numbers

Posted by Georgios Petasis <pe...@apache.org>.
Στις 18/12/2018 15:40, ο Massimo Manghi έγραψε:
> Automake generated Makefile uses a clever way to generate the Rivet's 
> packages index by running tclsh and pkg_mkIndex within the 'install' 
> target of the Makefile. CMakeList.txt doesn't provide the same feature 
> and in principle pure CMake builds, where version numbers change, end 
> up installing a wrong pkgIndex.
>
> We could probably agree on a different approach requiring the 
> repository to always store a consistent pkgIndex.tcl file by moving 
> the index generation in a specialized Makefile target (we do provide 
> binary packages too whose version number is stored in rivet_config.h). 
> This target could be run every time some version number (Rivet's own 
> version number included) changes. I know it's not automatic, but it's 
> not a frequent event either. I don't know if this target can be 
> replicated in CMAke but it's probably useless to try to implement it 
> provided we take care to keep pkgIndex.tcl consistent, no matter how 
> it was generated.
>
>  -- Massimo

Dear Massimo,

I have committed an update to CMakeLists.txt (master branch), which:
1) After libs have been installed, writes a file 
"regenerate_pkgIndex.tcl", inside the installation directory.
2) Puts in the file:
"puts \"Regenerating pkgIndex.tcl in [pwd]:\"
file delete {*}[glob [file join packages * pkgIndex.tcl]] pkgIndex.tcl
pkg_mkIndex -verbose [pwd] init.tcl \\
       {*}[glob [file join packages * *.tcl] \\
       [file join ${RIVET_LIBS_ARCH} *[info sharedlibextension]]]"
3) Executes the file with tclsh (it will break if tclsh is not found 
during configuration)
4) Deletes the file.

I have replaced "eval" with "{*}". Eval will break if paths contain 
spaces (very common in Windows). "{*}" will break in old tcl versions (I 
do not remember when it was introduced).

*I do not know what it should be put in RIVET_LIBS_ARCH*.

Best,

George

Re: Rivet pkgIndex.tcl version numbers

Posted by Georgios Petasis <pe...@iit.demokritos.gr>.
Στις 18/12/2018 15:40, ο Massimo Manghi έγραψε:
> Automake generated Makefile uses a clever way to generate the Rivet's 
> packages index by running tclsh and pkg_mkIndex within the 'install' 
> target of the Makefile. CMakeList.txt doesn't provide the same feature 
> and in principle pure CMake builds, where version numbers change, end 
> up installing a wrong pkgIndex.
>
> We could probably agree on a different approach requiring the 
> repository to always store a consistent pkgIndex.tcl file by moving 
> the index generation in a specialized Makefile target (we do provide 
> binary packages too whose version number is stored in rivet_config.h). 
> This target could be run every time some version number (Rivet's own 
> version number included) changes. I know it's not automatic, but it's 
> not a frequent event either. I don't know if this target can be 
> replicated in CMAke but it's probably useless to try to implement it 
> provided we take care to keep pkgIndex.tcl consistent, no matter how 
> it was generated.
>
>  -- Massimo

Dear Massimo,

I have committed an update to CMakeLists.txt (master branch), which:
1) After libs have been installed, writes a file 
"regenerate_pkgIndex.tcl", inside the installation directory.
2) Puts in the file:
"puts \"Regenerating pkgIndex.tcl in [pwd]:\"
file delete {*}[glob [file join packages * pkgIndex.tcl]] pkgIndex.tcl
pkg_mkIndex -verbose [pwd] init.tcl \\
       {*}[glob [file join packages * *.tcl] \\
       [file join ${RIVET_LIBS_ARCH} *[info sharedlibextension]]]"
3) Executes the file with tclsh (it will break if tclsh is not found 
during configuration)
4) Deletes the file.

I have replaced "eval" with "{*}". Eval will break if paths contain 
spaces (very common in Windows). "{*}" will break in old tcl versions (I 
do not remember when it was introduced).

*I do not know what it should be put in RIVET_LIBS_ARCH*.

Best,

George