I am looking to make a parrot rpm for mandrake and in same time, cleaning a=
nd=20
beautify the spec in the parrot cvs, but I am lock because the make install=
=20
and the MANIFEST.* generation doesn't works as it should:
=2D path are the same in MANIFEST.* and the install
=2D library are not installed
=2D path are mixing doc and other things
=2D mix parrot library file and .so files.
So the things I am thinking:
In MANIFEST{,.generated}: path/of/file [package]dirmacro
where dirmacro is $(LIBDIR) $(BINDIR) $(INCLUDEDIR) $(PARROTLIBDIR).
But libparrot.so is in blib/lib, the installed path is expand to=20
$(LIBDIR)/blib/lib, which is wrong, so only $(PARROTLIBDIR) should keep the=
=20
full path, other should install the as PATH/`basename of file`:
blib/lib/libparrot.so =3D> $(LIBDIR)/libparrot.so
whatever/file.pmc =3D> $(PARROTLIBDIR)/whatever/file.pmc
Currently there is two scripts (mk_manifests.pl, install_files.pl) but it d=
oes=20
not expand path in same way, so MANIFEST.* are wrong, I purpose to merge=20
those two script and let install_files.pl genrerate MANIFEST*.
Only after cleaning the installation I will be able to make a parrot.spec a=
s I=20
promise on #parrot. Of course if you agree with this solution, I'll make a=
=20
patch.
WDYT ? any comment ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQBCJc7yk29cDOWzfVARAgACAJ9hCVqNGuONFvd9U7Esnz79lAbuXwCgvbTq
B8K9u21MnLA4iwxdRxlA0fw=
=FfEz
-----END PGP SIGNATURE-----
Olivier Thauvin wrote:
> I am looking to make a parrot rpm for mandrake and in same time, cleaning and
> beautify the spec in the parrot cvs, but I am lock because the make install
> and the MANIFEST.* generation doesn't works as it should:
> - path are the same in MANIFEST.* and the install
> - library are not installed
> - path are mixing doc and other things
> - mix parrot library file and .so files.
Yeah. It was also reported that parrot.exe wasn't installed, IIRC.
> So the things I am thinking:
> blib/lib/libparrot.so => $(LIBDIR)/libparrot.so
> whatever/file.pmc => $(PARROTLIBDIR)/whatever/file.pmc
Sounds reasonable. What about the icu files?
> Currently there is two scripts (mk_manifests.pl, install_files.pl) but it does
> not expand path in same way, so MANIFEST.* are wrong, I purpose to merge
> those two script and let install_files.pl genrerate MANIFEST*.
I don't know. Maybe crate/use a module that has the common parts.
> Only after cleaning the installation I will be able to make a parrot.spec as I
> promise on #parrot. Of course if you agree with this solution, I'll make a
> patch.
>
> WDYT ? any comment ?
I appreciate getting "make install rpms" working very much. But I can't
say much about, how it should work ;)
leo
Leopold Toetsch writes:
> Olivier Thauvin wrote:
>> I am looking to make a parrot rpm for mandrake and in same time, cleaning
>> and beautify the spec in the parrot cvs, but I am lock because the make
>> install and the MANIFEST.* generation doesn't works as it should:
>> - path are the same in MANIFEST.* and the install
>> - library are not installed
>> - path are mixing doc and other things
>> - mix parrot library file and .so files.
>
> Yeah. It was also reported that parrot.exe wasn't installed, IIRC.
>
>> So the things I am thinking:
>
>> blib/lib/libparrot.so => $(LIBDIR)/libparrot.so
>> whatever/file.pmc => $(PARROTLIBDIR)/whatever/file.pmc
>
> Sounds reasonable. What about the icu files?
If we're going to be installing our own copy of icu, it would be nice if
we didn't accidentally overwrite an existing system ICU. (so, put them
somewhere under PARROTLIBDIR?)
Also, if the goal here is to get a distro, I'd recommend making the parrot
distro just have a dependency on the (hopefully pre-existing) ICU distro.
Le Wednesday 2 March 2005 17:04, Leopold Toetsch a =E9crit :
> Olivier Thauvin wrote:
> > I am looking to make a parrot rpm for mandrake and in same time, cleani=
ng
> > and beautify the spec in the parrot cvs, but I am lock because the make
> > install and the MANIFEST.* generation doesn't works as it should:
> > - path are the same in MANIFEST.* and the install
> > - library are not installed
> > - path are mixing doc and other things
> > - mix parrot library file and .so files.
>
> Yeah. It was also reported that parrot.exe wasn't installed, IIRC.
This is normal, the Makefile build parrot$(EXE) but the MANIFEST.generated=
=20
relate blib/bin/parrot.
>
> > So the things I am thinking:
> >
> > blib/lib/libparrot.so =3D> $(LIBDIR)/libparrot.so
> > whatever/file.pmc =3D> $(PARROTLIBDIR)/whatever/file.pmc
>
> Sounds reasonable. What about the icu files?
icu use autotools, maybe let autotools decide, but we should find a way to=
=20
passe CFLAGS and path to configure.
There is a pb here, .so become .dll on windows, binary become binary.exe,=20
ect...
>
> > Currently there is two scripts (mk_manifests.pl, install_files.pl) but =
it
> > does not expand path in same way, so MANIFEST.* are wrong, I purpose to
> > merge those two script and let install_files.pl genrerate MANIFEST*.
>
> I don't know. Maybe crate/use a module that has the common parts.
>
> > Only after cleaning the installation I will be able to make a parrot.sp=
ec
> > as I promise on #parrot. Of course if you agree with this solution, I'll
> > make a patch.
> >
> > WDYT ? any comment ?
>
> I appreciate getting "make install rpms" working very much. But I can't
> say much about, how it should work ;)
I can make a clean rpm (I do it for while now) and I can help about the=20
installation process, for sure I will not look the C code.
Well before patching with closed eyes we have to define a way to define=20
packaged file. The actuall process is too limited and is a mixed between pe=
rl=20
script and Makefile.
=46or what I understand:
Configure.PL + makefile*.in =3D> Makefile
Script + MANIFEST =3D> installation process.
There is an evident issue here: duplicate and mistmatch code.
I don't know how to make it better but I am looking for. MANIFEST.generated=
is=20
a bad idea anyway.
Why not having only one makefile ?
Why not let make install generated files ?
Are Manifest.* very usefull ? those file can be used only by rpm, is the=20
installation process is not here to make the packager works.
I just open some questions here.
If I had choice:
=2D do not make MANIFEST.* =3D> rpm packager job
=2D adding an install target in Makefile for all file instead having a perl=
=20
script + fixed lists for installation
This is only my point of view.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQBCJjZWk29cDOWzfVARAoKoAJ9rbutfbQc3x0xYbh/Q6hv8I9Wx2wCfegtB
knBBXyO792KUoh4BioeUvnI=
=nW9B
-----END PGP SIGNATURE-----
Olivier Thauvin wrote:
> Le Wednesday 2 March 2005 17:04, Leopold Toetsch a écrit :
>>>blib/lib/libparrot.so => $(LIBDIR)/libparrot.so
>>>whatever/file.pmc => $(PARROTLIBDIR)/whatever/file.pmc
>>
>>Sounds reasonable. What about the icu files?
>
>
> icu use autotools, maybe let autotools decide, but we should find a way to
> passe CFLAGS and path to configure.
The configure / make steps are working basically. Installation is the
problem. We don't want to overwrite any system ICU files that might be
there. I think ICU libs should go to runtime/parrot/lib. But then
there's a problem, if parrot is installed or not as paths would differ.
> There is a pb here, .so become .dll on windows, binary become binary.exe,
> ect...
That's all abstracted already: $(SHARE_EXT), $(EXE), ...
> For what I understand:
> Configure.PL + makefile*.in => Makefile
> Script + MANIFEST => installation process.
Yes.
> There is an evident issue here: duplicate and mistmatch code.
Yes. As said, I'd factor out common parts into a perl module.
> Why not having only one makefile ?
The root makefile is already big enough. languages/*/Makefile are
maintained by their owners. Distinct makefiles for various parts is a
good thing.
> Why not let make install generated files ?
We've to install on very different platforms. make syntax is quite
different. Doing it in perl is just easier IMHO, as all the platform
issues are handled by perl itself.
> Are Manifest.* very usefull ? those file can be used only by rpm, is the
> installation process is not here to make the packager works.
MANIFEST is the canonical list of all files. It's essential.
MANIFEST.generated is the list of generated items to install and where
to install it. Seems to be quite ok.
> I just open some questions here.
>
> If I had choice:
> - do not make MANIFEST.* => rpm packager job
I'd say, first fix "make install", then have a look at rpms.
> - adding an install target in Makefile for all file instead having a perl
> script + fixed lists for installation
Or probably better, just fix the perl script by adding redirections e.g.
'blib/lib' => '$(PARROTLIBDIR)'
leo
Le Thursday 3 March 2005 10:14, Leopold Toetsch a =E9crit :
> Olivier Thauvin wrote:
> > Le Wednesday 2 March 2005 17:04, Leopold Toetsch a =E9crit :
> >>>blib/lib/libparrot.so =3D> $(LIBDIR)/libparrot.so
> >>>whatever/file.pmc =3D> $(PARROTLIBDIR)/whatever/file.pmc
> >>
> >>Sounds reasonable. What about the icu files?
> >
> > icu use autotools, maybe let autotools decide, but we should find a way
> > to passe CFLAGS and path to configure.
>
> The configure / make steps are working basically. Installation is the
> problem. We don't want to overwrite any system ICU files that might be
> there. I think ICU libs should go to runtime/parrot/lib. But then
> there's a problem, if parrot is installed or not as paths would differ.
>
> > There is a pb here, .so become .dll on windows, binary become binary.ex=
e,
> > ect...
>
> That's all abstracted already: $(SHARE_EXT), $(EXE), ...
>
> > For what I understand:
> > Configure.PL + makefile*.in =3D> Makefile
> > Script + MANIFEST =3D> installation process.
>
> Yes.
>
> > There is an evident issue here: duplicate and mistmatch code.
>
> Yes. As said, I'd factor out common parts into a perl module.
>
> > Why not having only one makefile ?
>
> The root makefile is already big enough. languages/*/Makefile are
> maintained by their owners. Distinct makefiles for various parts is a
> good thing.
>
OK
> > Why not let make install generated files ?
>
> We've to install on very different platforms. make syntax is quite
> different. Doing it in perl is just easier IMHO, as all the platform
> issues are handled by perl itself.
>
OK
> > Are Manifest.* very usefull ? those file can be used only by rpm, is the
> > installation process is not here to make the packager works.
>
> MANIFEST is the canonical list of all files. It's essential.
> MANIFEST.generated is the list of generated items to install and where
> to install it. Seems to be quite ok.
I was talking aboug MANIFEST.perl6, MANIFEST.BASIC, ect...
MANIFEST.generated is not build itself, so setting "parrot [main]bin" will =
not=20
works on windows platform.
Maybe we should create it from MANIFEST.generated.in like Makefile.
>
> > I just open some questions here.
> >
> > If I had choice:
> > - do not make MANIFEST.* =3D> rpm packager job
>
> I'd say, first fix "make install", then have a look at rpms.
OK
>
> > - adding an install target in Makefile for all file instead having a pe=
rl
> > script + fixed lists for installation
>
> Or probably better, just fix the perl script by adding redirections e.g.
>
> 'blib/lib' =3D> '$(PARROTLIBDIR)'
I start to work on it ASAP.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQBCJv8kk29cDOWzfVARAouhAJoDAHjaAQFKUAmrXrXgtJPKq3J36QCgle/T
BkswxL5duNncbQbtCf5RRgA=
=ThrF
-----END PGP SIGNATURE-----