[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#238257: race condition on timestamps for cmi/mli files



On Tue, Mar 16, 2004 at 08:09:10AM -0600, John Goerzen wrote:
> On Tue, Mar 16, 2004 at 09:42:38AM +0100, Sven Luther wrote:
> > On Tue, Mar 16, 2004 at 12:49:45AM -0500, Mike Furr wrote:
> > > Hello ocaml-maint team,
> > > 
> > > While playing around with the OpenGL bindings, I came across this
> > > annoying behavior with OCamlMakefile.  It seems that during the
> > > installation of lablgl, the following timestamps occured:
> > 
> > Just don't use OcamlMakefile, i really don't like the concept myself,
> > and have had only trouble with it myself. And i guess writing a ocaml
> > Makefile is not all that different than writing a C one.
> 
> WRONG answer.

Come on, when i posted this, Remi had already provided constructive
info, so my post doesn't do any real harm. I should have used a smiley
or something for enphasis though, maybe.

And i really dislike the OcamlMakefile concept, it is not that it is
buggy per se, but it is used by people coming from java, and too lazy to
write a proper makefile themselves.

> If the package is so buggy that it should not be used, a bug should be
> filed against ftp.debian.org to have it removed.
> 
> I don't see you doing that.

No, i aknowledge that other use it, have no idea how it works in detail,
have had troubles with it each time i had to modify the makefile of a
package using it so it would do the proper thing with regard to
native/byte code. But hey, if other want to use it, fine for them.

> Actually, writing an OCaml Makefile is a fairly complex procedure,
> especially for a library, where there are files of different sorts to

Huh ? Never noticed such complexity myself. Most of the thing is pretty
straigthforward, and can be done with very basic Makefile knowledge.

> compile; you must generate both native and bytecode outputs, but on some
> platforms, only bytecode; you must install these in the appropriate

And, where is the problem ? You just provide both a _native and a
_bytecode target, or something such, and there is a documented way on
how to call the right thing from debian/rules (just check for the
existence of /usr/bin/ocamlopt).

> locations (maybe with findlib, maybe not); and if you use C code,

And, do you not need to install stuff in their right place in C ? For
libraries, the right place is just plain `ocamlc -where`/<name_of_lib>
anyway, except for the stublibs (stub library used for C binding). What
is the problem with that ? I don't really use findlib, i doubt there is
any real need for it in the debian library case, since it mostly
duplicates the debian package management, but it is nice for third party
stuff.

> there's the whole DLL generation thing.  It's not at all easy.

The DLL generation thingy is mostly one line in the makefile, and not
really worse than what you would do in C.

> OCamlMakefile *helps* for some projects.  I have found it lacking for

Yeah, for lazy programers who can't get bothered to write Makefiles,
sure it can help. But then, those are the one asking for java-like build
systems on the ocaml lists :)

> projects that generate multiple libraries or executables.  However, for
> the projects that don't have those requirements, it's useful.

But a nightmare to debian package, mostly because it don't even thinks
about the problems you mentioned above.

If you have trouble, please look at a library like camlzip :

### Configuration section

# The name of the Zlib library.  Usually -lz
ZLIB_LIB=-lz

# The directory containing the Zlib library (libz.a or libz.so)
ZLIB_LIBDIR=/usr/lib

# The directory containing the Zlib header file (zlib.h)
ZLIB_INCLUDE=/usr/include

# Where to install the library.  By default: sub-directory 'zip' of
# OCaml's standard library directory.
OCAMLLIBDIR=$(DESTDIR)`$(OCAMLC) -where`
INSTALLDIR=$(OCAMLLIBDIR)/zip
STUBLIBSDIR=$(OCAMLLIBDIR)/stublibs

### End of configuration section

OCAMLC=ocamlc -g
OCAMLOPT=ocamlopt
OCAMLDEP=ocamldep
OCAMLMKLIB=ocamlmklib

OBJS=zlib.cmo zip.cmo gzip.cmo
C_OBJS=zlibstubs.o

all: libcamlzip.a zip.cma

allopt: libcamlzip.a zip.cmxa

zip.cma: $(OBJS)
	$(OCAMLMKLIB) -o zip -oc camlzip $(OBJS) \
            -L$(ZLIB_LIBDIR) $(ZLIB_LIB)

zip.cmxa: $(OBJS:.cmo=.cmx)
	$(OCAMLMKLIB) -o zip -oc camlzip $(OBJS:.cmo=.cmx) \
            -L$(ZLIB_LIBDIR) $(ZLIB_LIB)

libcamlzip.a: $(C_OBJS)
	$(OCAMLMKLIB) -oc camlzip $(C_OBJS) \
            -L$(ZLIB_LIBDIR) $(ZLIB_LIB)

.SUFFIXES: .mli .ml .cmo .cmi .cmx

.mli.cmi:
	$(OCAMLC) -c $<
.ml.cmo:
	$(OCAMLC) -c $<
.ml.cmx:
	$(OCAMLOPT) -c $<
.c.o:
	$(OCAMLC) -c -ccopt -g -ccopt -I$(ZLIB_INCLUDE) $<

clean:
	rm -f *.cm*
	rm -f *.o *.a
	rm -f dllcamlzip.so

install:
	mkdir -p $(INSTALLDIR) 
	mkdir -p $(STUBLIBSDIR)
	cp zip.cma zip.cmi gzip.cmi zip.mli gzip.mli zlib.mli zlib.cmi libcamlzip.a $(INSTALLDIR)
	cp dllcamlzip.so $(STUBLIBSDIR)

installopt:
	cp zip.cmxa zip.a zip.cmx gzip.cmx $(INSTALLDIR)

depend:
	gcc -MM -I$(ZLIB_INCLUDE) *.c > .depend
	ocamldep *.mli *.ml >> .depend

include .depend

So, was that all that difficult ? Is there something you need to do that
is not basically covered here ? 

Friendly,

Sven Luther



Reply to: