Re: [cameleon-dev] Summoning the daemon : findlib migration RC1

[sylvain.le-gall]

On Fri, Jan 30, 2004 at 10:16:00AM +0100, Maxence Guesdon wrote:
> Hi Sylvain,
> 
> > Ok it has been a while i am working on a findlib migration...
> > 
> > It is done :
> > - to compile :
> >     - ./configure 
> >     - make 
> >     - make doc
> >     - make install
> >     - make install-doc
> > - for fun :
> >     - ./configure
> >     - make configure-options
> >     - make 
> >     - make doc
> >     - make install CONFIGURE=(absolute path + filename to your
> >     configure-options )- make install-doc CONFIGURE=(absolute path +
> >     filename to your configure-options )
> > 
> > I configure options you can choose a set of things to install, where to
> > install, should be byte or opt...
> 
> It seems very complicated. ./configure can already be used to set options, you
> know :-)
> And the DESTDIR variable (in master.Makefile.in) can already be used to
> install in a different directory (it is used by debian packagers).
> What's the need for other options and moreover for another configuration 
> system ?
>  

Ok, i perfectly see your point. I don't have explain it, but
configure-options is optional... It doesn't aim to replace ./configure
at all. It is only a consequence of my debian ocaml packaging
experience. Ie : destdir are useful not for the whole package but for
each library. Ie, okey will be installed in
$(CURDIR)/debian/libokey-ocaml-dev/usr/lib/ocaml/3.07/cameleon,
configwin in
$(CURDIR)/debian/libconfigwin-ocaml-dev/usr/lib/ocaml/3.07/cameleon,
etc

Maybe you see the point : you need a destdir file per library -- same
for application. Being able to define a destdir per application is heavy
to set in configure ( ie you need one option per library / application
). Anothr point is that configure-options is created automatically from
every single makefile. This mean, that if tomorrow i add library shaman,
i only need to add a dir and a makefile :

$(eval $(call ADD_TARGET_LIBRARY,shaman,shaman.ml,,,,))

That's all : configure-options will be updated accordingly etc...

Ie, configure-options is lightweight and was made only because it was
simple to do ( i add a target configure in every ADD_TARGET_* and that
was all -- all makefile as taken this into account ).


> > At the first compilation, you will think the output is NOT really
> > verbose... To reenable : make VERBOSE=yes.
> 
> Default should be VERBOSE=YES, i think.
>  

I don't think non-developper user are interested in the compilation
command line... Moreover, it is only useful when you have bugs when
compiling ( ie if it doesn't compile you should pass VERBOSE=yes ). Rest
of the time, it is only tons of command. Another point, is that ONLY
errors are outputed.... It is very interesting because you can find fast
where are errors and warning ( after having add this VERBOSE, i found 5
or 6 warning about deprecated antislash things... Doesn't have
corrected, but now i can see it ).

I think this option is mainly about outputing only what is important...

> > Now, some comments.
> > 
> > I choose to use configure-options because it is really a good ways to
> > configure a lot of things at once and it is done automatically ( ie,
> > when you add a library in a subdir, it will automatically take it into
> > account in the configure-options ).
> > 
> > You should feel that the build design is weird... Indeed it is. As i
> > stated before, i use this as a proof of concept for another build
> > system. However, it is really simple :
> > 
> > You want to compile program foo, which top file is top.ml ( you don't
> > need to stat the depends ) :
> > 
> > $(eval $(call ADD_TARGET_PROGRAM,top,best,top.cmx,,))
> > 
> > It needs unix to compile :
> > 
> > $(eval $(call SET_REQUIRES,top,prog,unix,,,,,,))
> > 
> > The file notop.ml need a special syntax :
> > 
> > $(eval $(call SET_SYNTAX,notop.ml,ioXml,camlp4o))
> 
> You call that "simple" ??? :-)
> Well, I think it's eird, indeed :-) I'll have a closer look at it
> to see if I can understand it... (I keep an open mind ;-)
> 

Well, it is simple.... You have almost nothing to write to compile a new
module. Another point is that, since all is evaluated through the call,
you can add a lot of options in the call needed to add new targets et
al... 

For example, i begin to rewrite all the makefile with $(eval $(call and
then i add target all, install in master.Makefile.in. I don't need to
touch anymore to Makefile.

Well, the $(eval and $(call are not very well known in makefile... But
trying to build something, i discover a lot of cryptic functions in make
and try to use it at best. 

>  
> > I think the best way is to have a look at master.Makefile.in ( there is
> > a full section with comment about all the top target you can use ).
> > 
> 
> I'll read comments to. It sure will help me :-)
>  
> > Right now, the non-ocamlfind build is not possible, but it is just a
> > matter of philosophy. To reenable it, i should add some functions in
> > master.Makefile.in ( it is not complicated, but it is a rewrite of
> > ocamlfind, and i don't like that ).
> > 
> > 
> > OK, so what the real purpose of my mail :
> > 
> > I need some beta testers.
> > I want to know, if all dev agreed on only using ocamlfind ( and not
> > non-ocamlfind ). However, it won't be definitive, as i have explain it
> > is just a matter of philosophy.
> > I want to have the authorization to merge HEAD with findlib.
> > 
> > If some of you can try to build...
> > 
> > I have made a tag : findlib-rc1
> > 
> > So for those who want to test :
> > cvs -z3 -d address@hidden:/cvsroot/cameleon co -r findlib-rc1
> > cameleon
> > 
> > I am waiting for your reaction... Don't hesitate to submit bugs ( maybe
> > tagged with findlib... need to create a special tag ).
> 
> Ok, I'll try it but not before one week or two (I'm very busy and want to
> finish some stuff on camlget really soon). I'll let you know when I tried
> your new compilation scheme.
> 
> Anyway, thanks for your work ;-)
> 
> Friendly,
> 
> Maxence
> 

Ok, i hope you will enjoy this. I spend a lot of time to make things
more simple. But i am working on another kind of build system, inspired
from this experience... So, i welcome any comments ;-)

Next week i will switch on zoggy2. It will gives you time to see all
this. 

Kind regard
Sylvain LE GALL