[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[SF Markus Elfring]

Hello,

I try to regenerate your current software from the Git repository on my openSUSE
system. I stumble on the following issue.

elfring at Sonne:~/Projekte/Coccinelle/Bau> ../lokal/configure --enable-opt
--enable-ocaml --enable-python --enable-release
configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
configure: configuring coccinelle 1.0.0-rc15 in
/home/elfring/Projekte/Coccinelle/Bau
...
configure: configuring package menhirLib
checking for OCaml findlib package menhirLib... not found
configure: OCaml package menhirLib is not available
checking for a bundled substitute of menhirLib... not available
configure: error: OCaml package menhirLib is required. Please make sure it is
available.


This library is installed under the directory "/usr/local/share/menhir" and is
found if I let the configuration script run while the source "lokal" is also the
working directory.
Would you like to adjust any configuration checks to support an
"out-of-source-tree build"? (How do you think about to store generated files in
a separate directory hierarchy here?)
https://github.com/coccinelle/coccinelle/blob/abad11c5570b7b9bbae5ff92b3050cf68fe3fd14/configure.ac#L146

Regards,
Markus

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[Julia Lawall]

On Sat, 2 Mar 2013, SF Markus Elfring wrote:

> Hello,
> 
> I try to regenerate your current software from the Git repository on my openSUSE
> system. I stumble on the following issue.
> 
> elfring at Sonne:~/Projekte/Coccinelle/Bau> ../lokal/configure --enable-opt
> --enable-ocaml --enable-python --enable-release
> configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
> configure: configuring coccinelle 1.0.0-rc15 in
> /home/elfring/Projekte/Coccinelle/Bau
> ...
> configure: configuring package menhirLib
> checking for OCaml findlib package menhirLib... not found
> configure: OCaml package menhirLib is not available
> checking for a bundled substitute of menhirLib... not available
> configure: error: OCaml package menhirLib is required. Please make sure it is
> available.
> 
> 
> This library is installed under the directory "/usr/local/share/menhir" and is
> found if I let the configuration script run while the source "lokal" is also the
> working directory.
> Would you like to adjust any configuration checks to support an
> "out-of-source-tree build"? (How do you think about to store generated files in
> a separate directory hierarchy here?)
> https://github.com/coccinelle/coccinelle/blob/abad11c5570b7b9bbae5ff92b3050cf68fe3fd14/configure.ac#L146

I'm not completely sure what you are proposing.  Perhaps you could just 
make a patch that does what you want?

julia

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[SF Markus Elfring]

> I'm not completely sure what you are proposing.

Have you got any idea why I get a result like the following?

elfring at Sonne:~/Projekte/Coccinelle/Bau> ocamlfind query camlp4 && ocamlfind
query menhirLib
/usr/lib64/ocaml/camlp4
ocamlfind: Package `menhirLib' not found


Are there any configuration challenges to consider with the use of a locally
installed variant in comparison to the version for this library which you also
bundle with your software?

Regards,
Markus

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[Julia Lawall]

On Mon, 4 Mar 2013, SF Markus Elfring wrote:

> > I'm not completely sure what you are proposing.
>
> Have you got any idea why I get a result like the following?
>
> elfring at Sonne:~/Projekte/Coccinelle/Bau> ocamlfind query camlp4 && ocamlfind
> query menhirLib
> /usr/lib64/ocaml/camlp4
> ocamlfind: Package `menhirLib' not found
>
>
> Are there any configuration challenges to consider with the use of a locally
> installed variant in comparison to the version for this library which you also
> bundle with your software?

I don't know what strategy ocamlfind follows, in detail.  Perhaps it would
be more reasonable to take up the problem with them, since it is a general
problem?

I'm not sure to understand the relevance of the fact that we bundle the
library.  The problem is that ocamlfind is not finding what you expect it
to find.

julia

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[Julia Lawall]

On Mon, 4 Mar 2013, Julia Lawall wrote:

> On Mon, 4 Mar 2013, SF Markus Elfring wrote:
>
> > > I'm not completely sure what you are proposing.
> >
> > Have you got any idea why I get a result like the following?
> >
> > elfring at Sonne:~/Projekte/Coccinelle/Bau> ocamlfind query camlp4 && ocamlfind
> > query menhirLib
> > /usr/lib64/ocaml/camlp4
> > ocamlfind: Package `menhirLib' not found
> >
> >
> > Are there any configuration challenges to consider with the use of a locally
> > installed variant in comparison to the version for this library which you also
> > bundle with your software?
>
> I don't know what strategy ocamlfind follows, in detail.  Perhaps it would
> be more reasonable to take up the problem with them, since it is a general
> problem?

If they say that it is not their problem, then I guess we could do
something.  But it seems strange for every piece of software that uses
ocamlfind to have to repeat the same piece of code.

julia

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[SF Markus Elfring]

> I'm not sure to understand the relevance of the fact that we bundle the
> library.  The problem is that ocamlfind is not finding what you expect it
> to find.

Is the OCaml package "menhirLib" generally found in your configuration even if
you try out a different build directory?

Regards,
Markus

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[Julia Lawall]

On Mon, 4 Mar 2013, SF Markus Elfring wrote:

> > I'm not sure to understand the relevance of the fact that we bundle the
> > library.  The problem is that ocamlfind is not finding what you expect it
> > to find.
>
> Is the OCaml package "menhirLib" generally found in your configuration even if
> you try out a different build directory?

I have one machine where it is not installed and one machine where it is
installed in the standard place.

I'm not sure to understand "try different build directory".  You mean you
want to put the executable in a place that is different than the source
code?

julia

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[SF Markus Elfring]

> I'm not sure to understand "try different build directory".  You mean you
> want to put the executable in a place that is different than the source
> code?

Yes. - It is the purpose to store such generated files by an "out-of-source-tree
build" separately.
http://programmers.stackexchange.com/questions/88792/automake-how-to-keep-the-source-tree-clean
http://stackoverflow.com/questions/1783111/fix-source-file-search-path-when-doing-out-of-source-autotools-build-within-emac

Regards,
Markus

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[SF Markus Elfring]

> I'm not sure to understand "try different build directory".  You mean you
> want to put the executable in a place that is different than the source code?

Yes. - Which file organisation do you prefer?
How do you think about the wording "parallel (or VPATH) build" instead of
"out-of-source build"?
http://www.gnu.org/software/automake/manual/html_node/VPATH-Builds.html

Regards,
Markus

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[SF Markus Elfring]

> I don't know what strategy ocamlfind follows, in detail.  Perhaps it would be
> more reasonable to take up the problem with them, since it is a general problem?

I have repeated the following command once more.

Sonne:/home/elfring/Projekte/Menhir/20130116 # make -j6 PREFIX=/usr/local install


Now I get an expected result.

elfring at Sonne:~/Projekte/Coccinelle/Bau> ocamlfind query menhirLib
/usr/lib64/ocaml/site-lib/menhirLib


It seems that I was affected by a "questionable" installation order. I am
curious on improvements also for this software library.
http://pauillac.inria.fr/~fpottier/menhir/

Does it eventually need better configuration checks?


But I notice another surprise.

elfring at Sonne:~/Projekte/Coccinelle/Bau> ../lokal/configure --enable-opt
--enable-ocaml --enable-python --enable-release
configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
configure: configuring coccinelle 1.0.0-rc15 in
/home/elfring/Projekte/Coccinelle/Bau
...
checking for OCaml findlib package menhirLib... found
configure: verifying optional features
checking for menhir... /usr/local/bin/menhir
...
checking python version... 2.7 found
configure: python major version: 2
configure: looking for the corresponding python library
checking for PYTHON... no
../lokal/configure: line 15081:
/home/elfring/Projekte/Coccinelle/Bau/setup/fake-subst.sh: No such file or directory
configure: error: the python scripts feature is enabled but the pkg-config
python library is not found


How should this error message be resolved?
https://github.com/coccinelle/coccinelle/issues/9

Regards,
Markus

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[Julia Lawall]

On Mon, 4 Mar 2013, SF Markus Elfring wrote:

> > I don't know what strategy ocamlfind follows, in detail.  Perhaps it would be
> > more reasonable to take up the problem with them, since it is a general problem?
>
> I have repeated the following command once more.
>
> Sonne:/home/elfring/Projekte/Menhir/20130116 # make -j6 PREFIX=/usr/local install
>
>
> Now I get an expected result.
>
> elfring at Sonne:~/Projekte/Coccinelle/Bau> ocamlfind query menhirLib
> /usr/lib64/ocaml/site-lib/menhirLib
>
>
> It seems that I was affected by a "questionable" installation order. I am
> curious on improvements also for this software library.
> http://pauillac.inria.fr/~fpottier/menhir/
>
> Does it eventually need better configuration checks?

My impression is that the menhir developers have very few or no resources
to devote to the project now, so probably they are not interested in
making any improvements in this direction.

> But I notice another surprise.
>
> elfring at Sonne:~/Projekte/Coccinelle/Bau> ../lokal/configure --enable-opt
> --enable-ocaml --enable-python --enable-release
> configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
> configure: configuring coccinelle 1.0.0-rc15 in
> /home/elfring/Projekte/Coccinelle/Bau
> ...
> checking for OCaml findlib package menhirLib... found
> configure: verifying optional features
> checking for menhir... /usr/local/bin/menhir
> ...
> checking python version... 2.7 found
> configure: python major version: 2
> configure: looking for the corresponding python library
> checking for PYTHON... no
> ../lokal/configure: line 15081:
> /home/elfring/Projekte/Coccinelle/Bau/setup/fake-subst.sh: No such file or directory
> configure: error: the python scripts feature is enabled but the pkg-config
> python library is not found
>
>
> How should this error message be resolved?
> https://github.com/coccinelle/coccinelle/issues/9

Maybe you have python but not the developer libraries?

julia

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[SF Markus Elfring]

>> https://github.com/coccinelle/coccinelle/issues/9
> 
> Maybe you have python but not the developer libraries?

The package "python-devel 2.7.3-3.6.1" is installed at the moment.

I do not get the mentioned error message if I repeat the command from within the
source directory.

elfring at Sonne:~/Projekte/Coccinelle/lokal> make distclean && ./configure
--enable-opt --enable-ocaml --enable-python --enable-release


Regards,
Markus

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[Arie Middelkoop]

There is something else than you can try, although I cannot guarantee
that it (still) works. If it does not work, then you should forget
about it.

In a fresh checkout(!), configure with an extra configuration
parameter: --enable-ocamlbuild
This will configure the project to use ocamlbuild to resolve
dependencies and invoke the ocaml tools. The makefiles are still used
to invoke ocamlbuild with the appropriate parameters.

Ocamlbuild puts build outputs in a separate directory, thus it is
doing an out-of-source build.
You can probably make it also output ocamldoc files of all the source
files, although that is speculation. Understanding of ocamlbuild would
be required in that case.

Arie

2013/3/4 SF Markus Elfring <elfring@users.sourceforge.net>:
>>> https://github.com/coccinelle/coccinelle/issues/9
>>
>> Maybe you have python but not the developer libraries?
>
> The package "python-devel 2.7.3-3.6.1" is installed at the moment.
>
> I do not get the mentioned error message if I repeat the command from within the
> source directory.
>
> elfring at Sonne:~/Projekte/Coccinelle/lokal> make distclean && ./configure
> --enable-opt --enable-ocaml --enable-python --enable-release
>
>
> Regards,
> Markus

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[SF Markus Elfring]

> There is something else than you can try, although I cannot guarantee
> that it (still) works.

I see two references to the script "fake-subst.sh" in your current build
specification "configure.ac". Do they need any adjustments so that the
dependency on the python programming language can also be resolved during an
out-of-source build?

Regards,
Markus

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[Arie Middelkoop]

Does it work as it is supposed to be?

2013/3/7 SF Markus Elfring <elfring@users.sourceforge.net>:
>> There is something else than you can try, although I cannot guarantee
>> that it (still) works.
>
> I see two references to the script "fake-subst.sh" in your current build
> specification "configure.ac". Do they need any adjustments so that the
> dependency on the python programming language can also be resolved during an
> out-of-source build?
>
> Regards,
> Markus

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[SF Markus Elfring]

> Does it work as it is supposed to be?

It seems that the desired build configuration works also as expected on my
system with an out-of-source build after a small adjustment for a variable.
www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Build-Directories.html

diff --git a/configure.ac b/configure.ac
index 2f0f682..4905af0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -8,7 +8,7 @@ AC_CONFIG_MACRO_DIR([setup])
 AC_CONFIG_AUX_DIR([setup])
 AC_SUBST([CONFIGURE_FLAGS], ["$*"])
 AC_SUBST([COCCI_VERSION], ["$PACKAGE_VERSION"])
-AC_SUBST([COCCI_SRCDIR], ["$(pwd)"])
+AC_SUBST([COCCI_SRCDIR], ["$srcdir"])
 AC_MSG_NOTICE([configuring coccinelle $COCCI_VERSION in $COCCI_SRCDIR])
 AM_INIT_AUTOMAKE


I have got the impression that there are more update candidates to consider
since the macro call "AM_INIT_AUTOMAKE" was added.
https://github.com/coccinelle/coccinelle/blob/abad11c5570b7b9bbae5ff92b3050cf68fe3fd14/configure.ac#L13

- Would you like to drop the variable "COCCI_SRCDIR" eventually (because there
is a standard one available)?
- How do you think about to change comments in files like "Makefile.am"?

Regards,
Markus

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[SF Markus Elfring]

> I have got the impression that there are more update candidates to consider
> since the macro call "AM_INIT_AUTOMAKE" was added.

Are you going to update and complete any components from your build
specification and corresponding configuration scripts?

Regards,
Markus

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[Arie Middelkoop]

Unlikely, unless there is a clear need to do so.

2013/3/16 SF Markus Elfring <elfring@users.sourceforge.net>:
>> I have got the impression that there are more update candidates to consider
>> since the macro call "AM_INIT_AUTOMAKE" was added.
>
> Are you going to update and complete any components from your build
> specification and corresponding configuration scripts?
>
> Regards,
> Markus

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[SF Markus Elfring]

> Unlikely, unless there is a clear need to do so.

I wonder why you do not see the need for corrections in your current build
specification and corresponding configuration scripts so far.
https://github.com/coccinelle/coccinelle/blob/abad11c5570b7b9bbae5ff92b3050cf68fe3fd14/configure.ac

I recommend adjustments for places like the following.
1. A "working directory" should not be referenced by the macro call
'AC_SUBST([COCCI_SRCDIR], ["$(pwd)"])'.

2. I find it strange that OCaml source files are passed in the macro call
'AC_CONFIG_FILES([...])'.

http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Configuration-Files.html

3. How do you think about to rename the extension for the "top level Makefile"
to ".mk"?

4. How would you like to fix the following error message?
   elfring at Sonne:~/Projekte/Coccinelle/Bau> LANG=C make -j6 -f Makefile.config
   make: *** No targets.  Stop.

5. I find that your "Makefile.am" files became inappropriate.
   - outdated comments

   - Which subdirectories should be used?

http://www.gnu.org/software/automake/manual/html_node/Conditional-Subdirectories.html

   - Which source files should be assigned to the variable "spatch_SOURCES"?
     http://www.gnu.org/software/automake/manual/html_node/Program-Sources.html

   - When will the OCaml compiler and linker be called there?

Regards,
Markus

[Cocci] 1.0.0-rc17: Further fine-tuning for the build system?

[SF Markus Elfring]

> Unlikely, unless there is a clear need to do so.

How would you like to fix open issues from your build specification and
corresponding configuration scripts?

Regards,
Markus

[Cocci] 1.0.0-rc17: Further fine-tuning for the build system?

[Julia Lawall]

On Sun, 7 Apr 2013, SF Markus Elfring wrote:

> > Unlikely, unless there is a clear need to do so.
>
> How would you like to fix open issues from your build specification and
> corresponding configuration scripts?

Arie does not work for the project any more.  I don't think that it is
within the goals of Coccinelle as a research project to have a bulletproof
build system.  If you have a real need for Coccinelle and you have a real
system in which it is impossible to build it or use an existing
executable, then we can look into that.

julia

[Cocci] 1.0.0-rc17: Further fine-tuning for the build system?

[SF Markus Elfring]

> Arie does not work for the project any more.

Thanks for this information.

Who does maintain the affected build specification and corresponding
configuration scripts now?


> I don't think that it is within the goals of Coccinelle as a research project
> to have a bulletproof build system.

I would prefer a system with less mistakes.


> If you have a real need for Coccinelle and you have a real system in which
> it is impossible to build it or use an existing executable, then we can
> look into that.

I reported a few open issues for further consideration.

Regards,
Markus

[Cocci] 1.0.0-rc17: Further fine-tuning for the build system?

[Julia Lawall]

On Sun, 7 Apr 2013, SF Markus Elfring wrote:

> > Arie does not work for the project any more.
>
> Thanks for this information.
>
> Who does maintain the affected build specification and corresponding
> configuration scripts now?

No one.

julia

[Cocci] 1.0.0-rc17: Further fine-tuning for the build system?

[SF Markus Elfring]

>> Who does maintain the affected build specification and corresponding
>> configuration scripts now?
> 
> No one.

Your answer surprises me. Are you the project leader for this software?

Would you like to integrate any update suggestions for this area from me into
your source code repository?

Regards,
Markus

[Cocci] 1.0.0-rc17: Further fine-tuning for the build system?

[Julia Lawall]

On Sun, 7 Apr 2013, SF Markus Elfring wrote:

> >> Who does maintain the affected build specification and corresponding
> >> configuration scripts now?
> >
> > No one.
>
> Your answer surprises me. Are you the project leader for this software?

Yes, but build systems are very tricky and entirely out of my expertise.
As long as the system builds in some way, I don't see the need for
supporting every possible exotic combination.  Notably, building the
software from some directory other than the one in which the software is
located seems completely unnecessary, as far as I can see.

> Would you like to integrate any update suggestions for this area from me into
> your source code repository?

Perhaps, but perhaps not.  I don't want to make changes that are
inessential and that I don't understand.  Any thing that one person
proposes would have to be reviewed by someone else.

julia

[Cocci] 1.0.0-rc17: Further fine-tuning for the build system?

[SF Markus Elfring]

>> Are you the project leader for this software?
> 
> Yes, but build systems are very tricky and entirely out of my expertise.

I can eventually help to become used to the usual software development in this
application area.


> As long as the system builds in some way, I don't see the need for
> supporting every possible exotic combination.

I hope that mistakes will be fixed in the near future.


> Notably, building the software from some directory other than the one
> in which the software is located seems completely unnecessary, as far
> as I can see.

If you want to improve the Autotools setup, you will get this feature easily.
The usefulness of "out-of-source builds / parallel build trees" might become
obvious if more configuration variants will be considered for the software
generation.


> I don't want to make changes that are inessential and that I don't understand.

Would you like adjust Automake details?

How do you think about to start corrections with the selection of corresponding
make file names?


> Any thing that one person proposes would have to be reviewed by someone else.

Would Rene perform such review tasks eventually since he was involved as a
Github committer?

Regards,
Markus

[Cocci] 1.0.0-rc17: Further fine-tuning for the build system?

[Julia Lawall]

On Sun, 7 Apr 2013, SF Markus Elfring wrote:

> >> Are you the project leader for this software?
> >
> > Yes, but build systems are very tricky and entirely out of my expertise.
>
> I can eventually help to become used to the usual software development in this
> application area.
>
>
> > As long as the system builds in some way, I don't see the need for
> > supporting every possible exotic combination.
>
> I hope that mistakes will be fixed in the near future.
>
>
> > Notably, building the software from some directory other than the one
> > in which the software is located seems completely unnecessary, as far
> > as I can see.
>
> If you want to improve the Autotools setup, you will get this feature easily.
> The usefulness of "out-of-source builds / parallel build trees" might become
> obvious if more configuration variants will be considered for the software
> generation.
>
>
> > I don't want to make changes that are inessential and that I don't understand.
>
> Would you like adjust Automake details?
>
> How do you think about to start corrections with the selection of corresponding
> make file names?
>
>
> > Any thing that one person proposes would have to be reviewed by someone else.
>
> Would Rene perform such review tasks eventually since he was involved as a
> Github committer?

I don't think so.  The required expertises are quite different.

julia

[Cocci] 1.0.0-rc17: Further fine-tuning for the build system?

[SF Markus Elfring]

>>> I don't want to make changes that are inessential and that I don't understand.
>>
>> Would you like adjust Automake details?

Which update candidate would you like to improve next here?

Regards,
Markus

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[Richard W.M. Jones]

On Sat, Mar 16, 2013 at 09:07:20PM +0100, SF Markus Elfring wrote:
> > I have got the impression that there are more update candidates to consider
> > since the macro call "AM_INIT_AUTOMAKE" was added.
> 
> Are you going to update and complete any components from your build
> specification and corresponding configuration scripts?

[Since you asked me in private email to contribute to
this discussion ...]

I think you're being unreasonable asking the Coccinelle developers to
fix things, and hardly specifying what the problem is (from what I can
gather it's something to do with separated builds not working?).

In any case, supply patches, with clear explanations behind each one.

So far I see one patch, probably incomplete, and no clear explanation
for it.

http://people.redhat.com/rjones/how-to-supply-code-to-open-source-projects/

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[SF Markus Elfring]

> [Since you asked me in private email to contribute to this discussion ...]

I am trying to find more software developers and packagers who know the 
Autotools good enough. I hope that corresponding updates can be reviewed 
in a constructive way then.


> I think you're being unreasonable asking the Coccinelle developers to
> fix things, and hardly specifying what the problem is (from what I can
> gather it's something to do with separated builds not working?).

Are you used to conditions which should be considered for the topic 
"out-of-source builds / parallel build trees"?

I pointed out some open issues to make the build configuration 
consistent again.
https://systeme.lip6.fr/pipermail/cocci/2013-March/000220.html
http://article.gmane.org/gmane.comp.version-control.coccinelle/3054


> In any case, supply patches, with clear explanations behind each one.

I got responses from Julia that she is not in the mood for the 
integration of fixes for the current build setup so far.

Regards,
Markus

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[Richard W.M. Jones]

On Fri, Apr 26, 2013 at 11:10:45AM +0200, SF Markus Elfring wrote:
> I got responses from Julia that she is not in the mood for the
> integration of fixes for the current build setup so far.

>From what I can tell, there aren't any fixes (ie. proper patches fully
explained) for her to consider yet.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[SF Markus Elfring]

> From what I can tell, there aren't any fixes (ie. proper patches fully 
> explained) for her to consider yet. 

I will not provide long explanations and concrete patches if I get clear 
responses from the project leader that she does not want to decide on 
them so far.
When will any pull request become acceptable from an other Git repository?

Regards,
Markus

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[Richard W.M. Jones]

On Fri, Apr 26, 2013 at 11:36:19AM +0200, SF Markus Elfring wrote:
> 
> >From what I can tell, there aren't any fixes (ie. proper patches
> >fully explained) for her to consider yet.
> 
> I will not provide long explanations and concrete patches if I get
> clear responses from the project leader that she does not want to
> decide on them so far.

If you'd read what I linked to:

http://people.redhat.com/rjones/how-to-supply-code-to-open-source-projects/

then you'd see how to proceed.  It's NOT by badgering Coccinelle
upstream and trying to get other people to argue your case for you.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[SF Markus Elfring]

> It's NOT by badgering Coccinelle upstream

If Julia will show more willingness to handle patches for the build 
system, I am going also to invest more efforts into concrete fixes.


> and trying to get other people to argue your case for you.

I do not want that, too. But other software developers might have got a 
higher reputation so that their update suggestions or source code review 
advices get easier accepted than change requests from me.

Regards,
Markus

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[Julia Lawall]

On Fri, 26 Apr 2013, SF Markus Elfring wrote:

>
> > It's NOT by badgering Coccinelle upstream
>
> If Julia will show more willingness to handle patches for the build system, I
> am going also to invest more efforts into concrete fixes.
>
>
> > and trying to get other people to argue your case for you.
>
> I do not want that, too. But other software developers might have got a higher
> reputation so that their update suggestions or source code review advices get
> easier accepted than change requests from me.

My point of view regarding the build system is that, on the one hand, at
the moment, I don't have any local resources with expertise in build
systems and on the other hand the build setup is extremely critical.
So I am not currently willing to make changes without an actual need from
a user.  An actual need would be a case where it is impossible to build
Coccinelle in any way on a given machine.  It is not a case where eg out
of tree builds don't work or parallel builds don't work.  In those cases,
one can easily avoid the problem by building in another way.

If several people want to work on and validate any solution that adds some
such inessential functionality, then I might consider integrating the
change.  But I don't have the expertise to evaluate such patches myself,
so I won't integrate such patches if they have only been tested by the
submitter.

This doesn't apply to ML patches.  I have received several patches adding
support for various strange C extensions, and I have no problem with
integrating them.  The risk is lower and the potential benefit is higher.

julia

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[Peter Senna Tschudin]

Hello Markus,

I'm following this topic since your first message. I'm sure it is not
your intention, but to me, your tone is not friendly. You are adding
little and complaining a lot. I can see your frustration, but I have
the impression that you do not care about how people feel about your
E-mails. The problem is that when you want something and you are not
friendly, people will not want to help you. By the tone in your
E-mails, I do not want to help you.

The people involved, including Julia, are busy, and they know exactly
what the project goals are. So if something is going wrong with your
patches / requests, your first reaction should be always to understand
why it is going wrong. Your current approach will not get you very far
and you will not be happy with the results.

Coccinelle is a great project, and I can ensure you that all patches
that add to Coccinelle will be seriously considered to be applied.
This means that Julia and other people will consider the pros and cons
of the patch and decide if it worth or not to apply it. Nothing new on
this way of applying patches...

As a general advice for sending patches and asking features on Open
Source projects, I recommend that you consider changing your approach.
First understand why it went wrong, then adjust your needs to fit with
the project goals. If you do like this, you may find more people
wanting to help you.

[]'s

Peter



On Fri, Apr 26, 2013 at 12:15 PM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
>
>> It's NOT by badgering Coccinelle upstream
>
>
> If Julia will show more willingness to handle patches for the build system,
> I am going also to invest more efforts into concrete fixes.
>
>
>
>> and trying to get other people to argue your case for you.
>
>
> I do not want that, too. But other software developers might have got a
> higher reputation so that their update suggestions or source code review
> advices get easier accepted than change requests from me.
>
> Regards,
> Markus
>
> _______________________________________________
> Cocci mailing list
> Cocci at systeme.lip6.fr
> https://systeme.lip6.fr/mailman/listinfo/cocci



-- 
Peter

[Cocci] 1.0.0-rc16: Further fine-tuning for the build system?

[SF Markus Elfring]

> By the tone in your E-mails, I do not want to help you.

That is a pity. But I thank you very much for this feedback.


> As a general advice for sending patches and asking features on Open
> Source projects, I recommend that you consider changing your approach.
> First understand why it went wrong, then adjust your needs to fit with
> the project goals.

It seems that it is hard to find more software developers and reviewers 
who dare to fiddle with the build setup here.

Regards,
Markus

[Cocci] 1.0.0-rc17: Further fine-tuning for the build system?

[SF Markus Elfring]

> It's NOT by badgering Coccinelle upstream and trying to get
> other people to argue your case for you.

Which build system do you use for this software in Fedora?
http://pkgs.fedoraproject.org/cgit/coccinelle.git/

Regards,
Markus