[Cocci] new release: 1.0.1

[Cocci] new release: 1.0.1

[Julia Lawall]

Main changes:

* There is a --use-gitgrep option for using git grep to preselect files.
I'm not sure about the exact performance tradeoffs.

* Small improvement on the handling of "default:" in a switch.

* A change in the treatment of ... in functions that contain loops.  This
could potentially cause a performance problem, although I have not
observed it.  The previous version was incorrect, though.  Some further
performance improvements could be possible.

julia

[Cocci] release: 1.0.1: Checking installation dependencies

[SF Markus Elfring]

> Some further performance improvements could be possible.

I have successfully built this release also on my system a moment ago.
http://coccinelle.lip6.fr/distrib/coccinelle-1.0.1.tgz

The installation worked also as expected at a first look.
But I wonder about the following error message at the moment.

elfring at Sonne:~> spatch -version
There is no standard.iso in /home/elfring.
Are you sure you run a properly installed version of spatch ?\nNo 'spatch' nor 'spatch.opt' found in /home/elfring


If I reinstall a previous software release, I get an expected display instead.

spatch version 1.0.0-rc24 with Python support and with PCRE support


How should such a surprise be fixed?

Regards,
Markus

[Cocci] release: 1.0.1: Checking installation dependencies

[Quentin Lambert]

On 19/06/2015 20:20, SF Markus Elfring wrote:
>> Some further performance improvements could be possible.
> I have successfully built this release also on my system a moment ago.
> http://coccinelle.lip6.fr/distrib/coccinelle-1.0.1.tgz
>
> The installation worked also as expected at a first look.
> But I wonder about the following error message at the moment.
>
> elfring at Sonne:~> spatch -version
> There is no standard.iso in /home/elfring.
> Are you sure you run a properly installed version of spatch ?\nNo 'spatch' nor 'spatch.opt' found in /home/elfring
>
>
> If I reinstall a previous software release, I get an expected display instead.
>
> spatch version 1.0.0-rc24 with Python support and with PCRE support
>
>
> How should such a surprise be fixed?
Hi,
this is a bug,
can you send me a copy of the bash script at the address returned by 
"which spatch"

Regards,

Quentin
>
> Regards,
> Markus
> _______________________________________________
> Cocci mailing list
> Cocci at systeme.lip6.fr
> https://systeme.lip6.fr/mailman/listinfo/cocci

[Cocci] release: 1.0.1: Checking installation dependencies

[SF Markus Elfring]

> this is a bug,
> can you send me a copy of the bash script at the address returned by "which spatch"

Does the script template need any more fine-tuning?
https://github.com/coccinelle/coccinelle/blob/d6ce1786f27a05efa53cabeca92fc8e744a4b239/scripts/spatch.sh.in#L1

It seems that a detail like "64" was omitted in my case.
How should the current build system ensure that the variable "LIBDIR"
will be set to "/usr/local/lib64/coccinelle" for my configuration?

Regards,
Markus

[Cocci] release: 1.0.1: Checking installation dependencies

[SF Markus Elfring]

> How should such a surprise be fixed?

I can circumvent the open issue by a symbolic link for a while.

Sonne:~ # ln -s /usr/local/lib64/coccinelle /usr/local/lib/coccinelle


elfring at Sonne:~> spatch -version
spatch version 1.0.1 with Python support and with PCRE support


Regards,
Markus

[Cocci] release: 1.0.1: Checking installation dependencies

[Quentin Lambert]

On 20/06/2015 11:15, SF Markus Elfring wrote:
>> How should such a surprise be fixed?
> I can circumvent the open issue by a symbolic link for a while.
>
> Sonne:~ # ln -s /usr/local/lib64/coccinelle /usr/local/lib/coccinelle
>
>
> elfring at Sonne:~> spatch -version
> spatch version 1.0.1 with Python support and with PCRE support
I am trying to understand the build system in further details and
I would appreciate it if you could send me the commands you called when
you installed coccinelle, so that I can try to reproduce the bug.


Regards,
Quentin

[Cocci] release: 1.0.1: Checking installation dependencies

[SF Markus Elfring]

> I am trying to understand the build system in further details

The build scripts contain some update candidates for a while.


> and I would appreciate it if you could send me the commands
> you called when you installed coccinelle,

The corresponding command is just the ordinary "make install".


> so that I can try to reproduce the bug.

Do you work also with a subdirectory "lib64" occasionally?

Do settings need improvements for the variables "LIBDIR"
and "SHAREDIR" (in a script template)?
https://github.com/coccinelle/coccinelle/blob/d6ce1786f27a05efa53cabeca92fc8e744a4b239/scripts/spatch.sh.in#L1

Regards,
Markus

[Cocci] release: 1.0.1: Checking installation dependencies

[Quentin Lambert]

On 22/06/2015 16:17, SF Markus Elfring wrote:
>> I am trying to understand the build system in further details
> The build scripts contain some update candidates for a while.
>
>
>> and I would appreciate it if you could send me the commands
>> you called when you installed coccinelle,
> The corresponding command is just the ordinary "make install".
What about configure ? Did you specify "--libdir=/usr/local/lib64" ?
>
>> so that I can try to reproduce the bug.
> Do you work also with a subdirectory "lib64" occasionally?
>
> Do settings need improvements for the variables "LIBDIR"
> and "SHAREDIR" (in a script template)?
I did modify that since 1.0.1 release.
In case I missed something could you tell me the distrib you are using ?

[Cocci] release: 1.0.1: Checking installation dependencies

[SF Markus Elfring]

> What about configure ?

There are some software development ideas in the waiting queue.


> Did you specify "--libdir=/usr/local/lib64" ?

No.


>> Do settings need improvements for the variables "LIBDIR"
>> and "SHAREDIR" (in a script template)?
> I did modify that since 1.0.1 release.

Interesting.

How do you think about to make the assignment "@prefix@/lib" configurable
a bit more in the affected script template?


> In case I missed something could you tell me the distrib you are using ?

I guess that my usage of openSUSE does not really matter here.


Would you like to correct also corresponding error display commands?

Regards,
Markus

[Cocci] release: 1.0.1: Checking installation dependencies

[Luis R. Rodriguez]

On Tue, Jun 23, 2015 at 11:57:01AM +0200, SF Markus Elfring wrote:
> > What about configure ?
> 
> 
> > In case I missed something could you tell me the distrib you are using ?
> 
> I guess that my usage of openSUSE does not really matter here.
> 

I ran into the same issue FWIW, and also using OpenSUSE. I used the same fix
if I remember correctly.

 Luis

[Cocci] new release: 1.0.1

[Nicholas Mc Guire]

On Thu, 18 Jun 2015, Julia Lawall wrote:

> Main changes:
> 
> * There is a --use-gitgrep option for using git grep to preselect files.
> I'm not sure about the exact performance tradeoffs.
> 
> * Small improvement on the handling of "default:" in a switch.
> 
> * A change in the treatment of ... in functions that contain loops.  This
> could potentially cause a performance problem, although I have not
> observed it.  The previous version was incorrect, though.  Some further
> performance improvements could be possible.
>
just noticed that git pull says "Already up-to-date."
but there is no 1.0.1 tag ?

url = https://github.com/coccinelle/coccinelle - wrong repo ?

thx!
hofrat

[Cocci] new release: 1.0.1

[Julia Lawall]

On Wed, 24 Jun 2015, Nicholas Mc Guire wrote:

> On Thu, 18 Jun 2015, Julia Lawall wrote:
>
> > Main changes:
> >
> > * There is a --use-gitgrep option for using git grep to preselect files.
> > I'm not sure about the exact performance tradeoffs.
> >
> > * Small improvement on the handling of "default:" in a switch.
> >
> > * A change in the treatment of ... in functions that contain loops.  This
> > could potentially cause a performance problem, although I have not
> > observed it.  The previous version was incorrect, though.  Some further
> > performance improvements could be possible.
> >
> just noticed that git pull says "Already up-to-date."
> but there is no 1.0.1 tag ?
>
> url = https://github.com/coccinelle/coccinelle - wrong repo ?

I have the impression that github has not been updated. Someone else does
that.

julia

[Cocci] release: 1.0.1: Checking installation dependencies

[Quentin Lambert]

On 23/06/2015 19:28, Luis R. Rodriguez wrote:
> On Tue, Jun 23, 2015 at 11:57:01AM +0200, SF Markus Elfring wrote:
>>> What about configure ?
>>> In case I missed something could you tell me the distrib you are using ?
>> I guess that my usage of openSUSE does not really matter here.
>>
> I ran into the same issue FWIW, and also using OpenSUSE. I used the same fix
> if I remember correctly.
What I don't understand is why coccinelle was installed in /usr/local/lib64.
The pattern lib64 is not used at all in my version of coccinelle's 
source code
and when I installed coccinelle on openSUSE it did end up in lib rather 
than lib64.

Do any of you have an idea why coccinelle was installed in lib64?
Could you send me the result of
grep -n lib64
for coccinelle's directory after executing "./configure"?

Regards,
Quentin

[Cocci] release: 1.0.1: Checking installation dependencies

[SF Markus Elfring]

> The pattern lib64 is not used at all in my version of coccinelle's source code

How do you think about to recheck make files and related build scripts?


> and when I installed coccinelle on openSUSE it did end up in lib rather than lib64.

Which run time environment did you try out for this software installation test?


> Do any of you have an idea why coccinelle was installed in lib64?

Yes, in principle.   ;-)

How do you distinguish 64 bit systems nowadays?

Regards,
Markus

[Cocci] release: 1.0.1: Checking installation dependencies

[SF Markus Elfring]

> Do any of you have an idea why coccinelle was installed in lib64?

Did you already look at source files like the following?

elfring at Sonne:~/Projekte/Coccinelle/1.0.1> find . -type f -print | xargs grep -n SHAREDIR
?
./tools/sgen/scripts/sgen.sh.in:5:SHAREDIR=""${PREFIX}/lib/coccinelle/sgen""
./tools/sgen/scripts/sgen.sh.in:7:exec ""${SHAREDIR}/${TARGET}"" "$@"
./tools/sgen/source/Makefile:9:INSTALLDIR=$(DESTDIR)$(SHAREDIR)/sgen
./config.log:785:SHAREDIR='${exec_prefix}/lib64/coccinelle'


Does the build system need any more improvements?

Regards,
Maekus

[Cocci] release: 1.0.1: Checking installation dependencies

[Julia Lawall]

> > Do any of you have an idea why coccinelle was installed in lib64?
> 
> Yes, in principle.   ;-)
> 
> How do you distinguish 64 bit systems nowadays?

What does "Yes, in principle" mean?  Did you actually change anything to 
lib64, or specify lib64 on a command line, because you considered that on 
your 64 bit system that was the better choice?

Because there are hard coded instances of lib in the various configuration 
files.  So it seems hard to understand how a hard coded occurrence of lib 
could be transformed into lib64.

julia

[Cocci] release: 1.0.1: Checking installation dependencies

[SF Markus Elfring]

> What does "Yes, in principle" mean?

My knowledge might be still incomplete for this issue.


> Did you actually change anything to lib64, or specify lib64 on a command line,

No.


> because you considered that on your 64 bit system that was the better choice?

I find such technical detail still ordinary.


> Because there are hard coded instances of lib in the various configuration files.

Would it make sense to change this?


> So it seems hard to understand how a hard coded occurrence of lib 
> could be transformed into lib64.

How do you think about to add any dedicated configuration options?
Are additional variables needed?

Does this specific name "lib" refer to the well-known directory
where shared libraries should usually be stored?

Regards,
Markus

[Cocci] release: 1.0.1: Checking installation dependencies

[Julia Lawall]

> > Because there are hard coded instances of lib in the various configuration files.
> 
> Would it make sense to change this?

No idea.  But changing it at this point will not help to find the source 
of your problem.

julia

[Cocci] release: 1.0.1: Checking installation dependencies

[SF Markus Elfring]

> But changing it at this point will not help to find the source 
> of your problem.

Do we talk about the same meaning for the directory name "lib"?

Regards,
Markus

[Cocci] release: 1.0.1: Checking installation dependencies

[Julia Lawall]

On Thu, 2 Jul 2015, SF Markus Elfring wrote:

> > But changing it at this point will not help to find the source 
> > of your problem.
> 
> Do we talk about the same meaning for the directory name "lib"?

The issue is the sequence of letters /lib and /lib64, not what they mean.

julia

[Cocci] release: 1.0.1: Checking installation dependencies

[SF Markus Elfring]

> The issue is the sequence of letters /lib and /lib64, not what they mean.

I would like to be sure that such names refer to the usual directories
for shared libraries (and not to an folder anywhere else).

Regards,
Markus

[Cocci] release: 1.0.1: Checking installation dependencies

[Quentin Lambert]

I am very sorry, I must have made a mistake before I have successfully 
reproduced the bug
I am working on fixing it now.

On 02/07/2015 10:11, Julia Lawall wrote:
> On Thu, 2 Jul 2015, SF Markus Elfring wrote:
>
>>> But changing it at this point will not help to find the source
>>> of your problem.
>> Do we talk about the same meaning for the directory name "lib"?
> The issue is the sequence of letters /lib and /lib64, not what they mean.
>
> julia