On 15-04-12 23:28, Michael Stefaniuc wrote:
On 04/11/2012 11:01 AM, SF Markus Elfring wrote:
There have been significant changes to the makefile and to the management
of external libraries.
How do you think about to delete the script "configure" and any
auxiliary files from the source code repository because they can be
regenerated automatically?
Adding configure simplifies the building of the software by shielding
the users from having to deal with the autotools stuff. Other projects
do the same, e.g. Wine.
We have an optional dependency on the pkgconfig package, and configure
uses a number of macros to detect the pkg-config tool. These macros are
shipped with the pkgconfig package. Thus, if you want to generate the
configure script, the dependency on pkgconfig would not be optional anymore.
(speaking of which, if you don't have the optional pkg-config or
findlib, a shell script will try to guess the configuration parameters
by asking ocaml and python. I've just made a couple of minor
compatibility changes, and it works now with bash and zsh, so I guess
that solves the problem that Nicolas ran into).
Note also that the sources on github comprise a coccinelle distribution,
so it (should) contain a couple of (portable) pregenerated files such as
files generated by menhir, documentation generated by latex, and also
the configure script.
Feel free to run ./autogen.sh to regenerate the configure script, or
'make distclean' for the rest.
(autoreconf cannot be used because that would require that we use the
GNU conventions for some of our text files, e.g. a rename of install.txt
to INSTALL and readme.txt to README, which I'm not going to do unless it
really bothers someone)
(@Markus: FWIW, I've added the autoconf version requirement, although I
don't think that the version matters too much.)
As autotools (or in this case autoconf) is concerned: the m4 macro
notation is indeed ugly. In our case, it's mainly many conditionals, no
weird hacks, so that should be robust enough. It's advantage lies in
that it provides macros to standardize configuration behavior (e.g.
parameters and environment variables). We have a need to configure
things: coccinelle depends on several packages that are not directly
ocaml related (e.g. python libraries, pcre libraries). Also, we ship
some bundled packages that can be used if not yet available already, and
these need to be configured too.
What can be improved in the build system is the part related to ocaml.
I've for example looked into several issues in our Makefiles regarding
parallel and incremental compilation. Most of these issues originated
from a too straightforward Makefile approach, and are about details that
a developer should not have to know about. Indeed, most ocaml projects
use OCamlMakefile or ocamlbuild+oasis nowadays for more declarative
build descriptions. However, it's not straightforward to switch to such
systems; definitely not while keeping functionality such as pregenerated
files, menhir, compatibility with old ocaml versions...
Anyway, I guess we'll soon be releasing another release candidate. It'll
have fixes for the build issues that were reported, parallel building,
and finally also provides python-3.x support.
Arie
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)
