Hi Bill, Yes I completely understand why, at the moment, you have to build ocaml twice.
It all comes down to the fact that at present ocaml (eg. SUNWocaml) is *not* on the build servers. But once you have integrated these packages and the build server have been updated to the Nevada build with these pkgs in, SUNWocaml will be there - hence at that point the second build of ocaml is redundant (I think - correct me if I am wrong in thinking that). So why not just have a "Flag-Day" that says once you have integrated your stuff into the sfwnv-consolidation then "SUNWocaml must be installed" on *all* sfwnv build servers. While you are developing it though, you will also need it on the build server you use. But I expect the sfwnv gatekeeper will have some comments on what is the best way to do this - so seek advice there. Sorry, I'm not really trying to make your job integrating this hard. Paul :-) bill yan wrote: > > That would be greate if SUNWocaml can be pre-installed on build server. > > Currently, We have to bulid ocaml two times. one is for the SUNWocaml > package and the other is for the compliation of lablgtk and unison. This > is because during the compilation of lablgtk and unison , some ocaml > scripts which are interpreted by ocamlrun program are needed. > > For example, in ocamlc script, the first line is the location of > interpreter, as follows: > > #!/usr/bin/ocamlrun > > > For the ocamlc to be built into package SUNWocaml, the header should be: > > #!/usr/bin/ocamlrun > > > But with the header above, ocamlc can't be run during the compilation of > lablgtk and unison, because at that time, the path of ocamlrun is > $ROOT/usr/bin/ocamlrun(proto area), not /usr/bin/ocamlrun . So we need > to compile another ocamlc with the header $ROOT/usr/bin/ocamlrun(proto > area) to make sure it can be run during the compilatioin of lablgtk and > unison. > > > That's why we compile ocaml twice. We really appreciate that if you > could advise us the better solution based on the current situation. > > Regards, > Bill > > > Paul Cunningham ???: >> So finally ... >> >> I still don't see why you need to build and install the 'ocaml compiler' >> twice! (and two copies of the same source tarball) >> >> 1. built to be delivered as SUNWocaml >> 2. built as a temp tool to build lablgtk & unison. >> >> Just seems like a waste of machine resources to me. >> >> I would have thought it was best to have SUNWocaml installed on build >> boxes and it become a sfwnv build tool requirement. Then it's there when >> it comes to build unison & lablgtk. >> >> Is the sfwnv gatekeeper/c-team happy with you doing this pkg build twice >> per ws build? If so you can ignore my objections to this :-) >> >> Paul >> >> Liu Xin wrote: >> ... cut ... >> >>> Paul Cunningham: >>> >> ... cut ... >> >>>> Liu Xin wrote: >>>> >>>> >>>>> Please help review the fix of CR6689922 CR6739050 and CR6739053. Any >>>>> comments are welcome. Thanks. >>>>> >>>>> Webrev is at: >>>>> http://cr.opensolaris.org/~liuxin/ocaml_lablgtk_unison/ >>>>> <http://cr.opensolaris.org/%7Eliuxin/ocaml_lablgtk_unison/> >>>>> >>>>> >> >> ... cut .... >> >> >>>> === Start of Comments ==== >>>> >>>> 1. usr/src/cmd/Makefile >>>> Shouldn't unison have a build dependency on >>>> the ocaml compiler build? >>>> >>>> For lablgtk see comment (5) >>>> >>>> >>> The unison will use the ocaml compliler that installed in the temporary >>> dir by lablgtk. >>> We can not use the one that was built by ocaml/Makefile.sfw, >>> please see comment (3) >>> >>>> 2. usr/src/cmd/unison/Makefile.sfw >>>> Why are you moving stuff about that belongs to >>>> ocaml and lablgtk in this Makefile (lines 48-52), >>>> shouldn't that have been done in the builds of >>>> those packages at the appropriate time? >>>> >>>> >>> please see comment (3) first >>> >>> There are two ocaml now.One was built by ocaml/Makefile.sfw to be >>> installed into the proto area, the other installed in the temporary dir >>> by lablgtk/Makefile.sfw for compling. >>> The unison will use the ocaml compliler that installed in the temporary >>> dir by lablgtk/Makefile.sfw.(temporary >>> dir=/proto/root_sparc/usr/share/ocaml/) >>> But the lablgtk will be put under the ocaml dir that was built by >>> ocaml/Makefile.sfw in order to be installed into the right place.(the >>> ocaml dir=/proto/root_sparc/usr) >>> The unison also use the lablgtk ,so copy the lablgtk files to the >>> temporary dir for compling. >>> >> >> >>>> 3. usr/src/cmd/ocaml/Makefile.sfw >>>> Why are you 'configure'ing this twice? My guess >>>> is that you somehow want to be able to use the >>>> ocaml you put into the proto area to build >>>> unison - but the proto area should have the real >>>> SUNWocaml files in it. >>>> >>>> Use the default 'configure --prefix=..' value defined >>>> in Makefile.master (and any other defaults). You could >>>> also use the CONFIGURE_OPTIONS method, eg. >>>> './configure $(CONFIGURE_OPTIONS)' see other recent >>>> pkg integrations. >>>> >>>> >>> The ocaml built by ocaml/Makefile.sfw will generate several binary files >>> to install. >>> such as >>> ocamlc >>> ocamlcp >>> ocamlopt >>> ocamlrun >>> ...... >>> >>> Most of them need "ocamlrun" to run.They will be put in the proto area >>> as the the real SUNWocaml files >>> the 'configure --prefix=..' dose not only define the PATH where to >>> install them,but also defines where is the "ocamlrun" to run them. >>> For example >>> if use the 'configure --prefix=/usr',then build the source to generate >>> ocamlc ... >>> ======================== >>> #strings ocamlc | more >>> #!/usr/bin/ocamlrun >>> caml_alloc_dummy >>> ...... >>> >>> ======================== >>> >>> if use the 'configure --prefix=/$(ROOT)/usr' ,then build the source to >>> generate ocamlc ... >>> ======================== >>> #echo $ROOT >>> /builds/.../proto/root_sparc >>> # >>> #strings ocamlc | more >>> #!/builds/.../proto/root_sparc/usr/bin/ocamlrun >>> caml_alloc_dummy >>> ...... >>> ======================== >>> >>> So I use the first 'configure --prefix=/usr' to defines where is the >>> "ocamlrun" in the binary files (#!/usr/bin/ocamlrun) and build the >>> source to generate them, >>> then use the second 'configure --prefix=$(ROOT)/usr' to define the PATH >>> in the unison-2.27.57/makefile to install them to the proto area. >>> >>> Since the ocamlc and other binary files with '#!/usr/bin/ocamlrun' in >>> them can not run when they are in the proto area ($ROOT is not "/"), >>> we have to install them again when labgtk and unison need. >>> >>> There are two ocaml now. >>> One was built by ocaml/Makefile.sfw to be installed into the proto area, >>> the other installed in the temporary dir by lablgtk/Makefile.sfw for >>> compling. >>> Unison will use the one built by lablgtk/Makefile.sfw. >>> >>> >>> >>>> 4. usr/src/cmd/ocaml/install-sfw >>>> Add 'line space' after line 45 ('make install' line). >>>> Is this 'make install' actually installing it into the >>>> proto area (eg. no DESTDIR= or equivalent)? >>>> >>>> >>>> >>> Yes, the install path will be defined by the "configue" in the >>> Makefile.sfw . >>> 'make install' will use the makefile that is generated by the "configue". >>> >> >> .. cut .. >> >> >>>> 5. usr/src/cmd/lablgtk/Makefile.sfw >>>> Why are you building ocaml again in this lablgtk >>>> Makefile ? Shouldn't you be using the one that was built >>>> by ocaml/Makefile.sfw ? >>>> >>>> >>>> >>> please see comment (3) >>> >> >> ... cut ... >> >> >> >>>> 8. usr/src/cmd/lablgtk/ocaml-3.10.2.tar.gz >>>> & usr/src/cmd/ocaml/ocaml-3.10.2.tar.gz >>>> Why put this source tarball twice in gate? >>>> >>>> >>>> >>> please see comment (3) >>> >> >> ... cut ... >> >> >>>> === End of Comments ====== >>>> >> >> -- ---------------------------------------------------------------------- Paul Cunningham Software Engineer Tadpole Computer Products General Dynamics Itronix Europe Ltd. Pioneer House Chivers Way Histon, Cambridgeshire, UK, CB24 9NL Ph: +44 (0)1223 200648 FAX: +44 870 4324162 Email: paul.cunningham at tadpole.com This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message
