installation process of parrot

1 view
Skip to first unread message

Olivier Thauvin

unread,
Mar 2, 2005, 9:34:22 AM3/2/05
to perl6-i...@perl.org
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.

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
$(LIBDIR)/blib/lib, which is wrong, so only $(PARROTLIBDIR) should keep the
full path, other should install the as PATH/`basename of file`:
blib/lib/libparrot.so => $(LIBDIR)/libparrot.so
whatever/file.pmc => $(PARROTLIBDIR)/whatever/file.pmc

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*.

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 ?

Leopold Toetsch

unread,
Mar 2, 2005, 11:04:05 AM3/2/05
to Olivier Thauvin, perl6-i...@perl.org
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

Will Coleda

unread,
Mar 2, 2005, 12:44:42 PM3/2/05
to Leopold Toetsch, Olivier Thauvin, perl6-i...@perl.org
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.


Olivier Thauvin

unread,
Mar 2, 2005, 4:55:31 PM3/2/05
to perl6-i...@perl.org
Le Wednesday 2 March 2005 17:04, Leopold Toetsch a écrit :
> 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.

This is normal, the Makefile build parrot$(EXE) but the MANIFEST.generated
relate blib/bin/parrot.

>
> > 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?

icu use autotools, maybe let autotools decide, but we should find a way to
passe CFLAGS and path to configure.

There is a pb here, .so become .dll on windows, binary become binary.exe,
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.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 ;)

I can make a clean rpm (I do it for while now) and I can help about the
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
packaged file. The actuall process is too limited and is a mixed between perl
script and Makefile.

For what I understand:
Configure.PL + makefile*.in => Makefile
Script + MANIFEST => 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
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
installation process is not here to make the packager works.

I just open some questions here.

If I had choice:
- do not make MANIFEST.* => rpm packager job
- adding an install target in Makefile for all file instead having a perl
script + fixed lists for installation

This is only my point of view.

Leopold Toetsch

unread,
Mar 3, 2005, 4:14:16 AM3/3/05
to Olivier Thauvin, perl6-i...@perl.org
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

Olivier Thauvin

unread,
Mar 3, 2005, 7:12:20 AM3/3/05
to perl6-i...@perl.org
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
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.* => 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 perl
> > script + fixed lists for installation
>
> Or probably better, just fix the perl script by adding redirections e.g.
>
> 'blib/lib' => '$(PARROTLIBDIR)'

I start to work on it ASAP.

Reply all
Reply to author
Forward
0 new messages