Mailing List Archive

On Wed, 18 Oct 1995, Phillip Moore wrote:

> The default makefile generated by the perl5.001m Configure installed
> libperl.a and most of the perl5 header files into lib/perl5/CORE.
> This is a substantial amount of disk space for the multiple platforms
> we build perl5 on:

If you're sure no one will want to build a new static perl, you can
safely delete libperl.a. Keep the headers, though, because they
*are* needed for dynamic extensions. (They're not too big anyway.)

This is a good observation, though, and I'll make a note to put
something in INSTALL about it.

Andy Dougherty doughera@lafcol.lafayette.edu
Dept. of Physics
Lafayette College, Easton PA 18042

On Wed, 18 Oct 1995, Phillip Moore wrote:

> Andy> Keep the headers, though, because they *are* needed for dynamic
> Andy> extensions. (They're not too big anyway.)
>
> Hmm. truss and strace would seem to debunk this.

Sorry. I meant to say they are needed for *building* dynamic extensions.

Andy Dougherty doughera@lafcol.lafayette.edu

On Wed, 18 Oct 1995, Phillip Moore wrote:

> Given the significant space savings, particularly in a heterogenous
> environment, this should probably be an option one could specify in
> Configure.

I have no objection to this if anyone wants to submit a patch.

Andy Dougherty doughera@lafcol.lafayette.edu
--
To subscribe or unsubscribe, send your request (subscribe, unsubscribe)
in the BODY of a message to perl5-porters-request@africa.nicoh.com.

phillip> Sybase::DBlib
phillip> Tk
phillip> POSIX

phillip> I.e. a crude test was:

phillip> truss perl5 -e 'use Tk' 2>&1 | egrep CORE

There's probably another misunderstanding.

Try grep CORE /usr/local/lib/perl5/ExtUtils/MakeMaker.pm

Maybe you're not aware, that any user in any directory is able to
compile any extension *without* having access to the source tree --
which really takes up a considerable amount of diskspace.

If you want to save diskspace, tar and compress your perl source and
leave CORE as it is. Just a hint, not an imperative :)


andreas

On Wed, 18 Oct 1995, Andy Dougherty wrote:

> On Wed, 18 Oct 1995, Phillip Moore wrote:
>
> > The default makefile generated by the perl5.001m Configure installed
> > libperl.a and most of the perl5 header files into lib/perl5/CORE.
> > This is a substantial amount of disk space for the multiple platforms
> > we build perl5 on:
>
> If you're sure no one will want to build a new static perl, you can
> safely delete libperl.a. Keep the headers, though, because they
> *are* needed for dynamic extensions. (They're not too big anyway.)
>
> This is a good observation, though, and I'll make a note to put
> something in INSTALL about it.

Unless somebody is using embedding, in which case the libperl.a has a
useful role. (Worse yet, what if it is libperl.so, or libperl.dll, and is
used continously by all programs that embed perl, including "perl". This
is possible on some systems, right?)

> Andy Dougherty doughera@lafcol.lafayette.edu
> Dept. of Physics
> Lafayette College, Easton PA 18042
>
>

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

On Wed, 18 Oct 1995, Phillip Moore wrote:

> >>>>> "Andy" == Andy Dougherty <doughera@lafcol.lafayette.edu> writes:
> >>>>> "Phil" == Phillip Moore <wpm@ms.com> writes:
>
> Phil> Given the significant space savings, particularly in a
> Phil> heterogenous environment, this should probably be an option one
> Phil> could specify in Configure.
>
> Andy> I have no objection to this if anyone wants to submit a patch.
>
> Looks pretty trivial. I'll see if I can't put this together. Default
> answer obviously is yes.
>
> I also want to make installation of the pod files themselves optional,
> and make some changes such that the html files get installed as well.
> This means pod2html needs an option to open the output files somewhere
> other than the same place the sources are.
>
> I am a bit suprised that noone has tackled this before, as it seems
> pretty easy. Am I about to step into a pile of something I'd rather
> not?? Anyone been there, done that...

There is an update to the POD stuff "in the works", meaning I've been
working on it for some time now, and have started over a few times. But
the upshot of this is that it probably is a good idea to keep installing
the .pod files, as they will be more useful in future. (Think about
indexing, direct searches for entries, etc.)

As for mucking about with pod2html, ask around a bit for the latest
version, as it may have that feature, or it may not.

> Phil

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

> Given the significant space savings, particularly in a heterogenous
> environment, this should probably be an option one could specify in
> Configure.

You could also swipe a space saving method which the ISODE package uses
on a number of operationg systems. Add this at the end of the `.c.o:'
rule in makefile:

-ld -x -r $@ && mv a.out $@

That will get rid of non-global symbols, and thus trim down the .o and .a
files quite a bit. Though i'm not sure if it can be used if you build a
shared library, at least it cannot on SunOS.

Here is the list of configurations where ISODE uses it:
4.2BSD
RT PC running 4.3BSD
4.3BSD
4.4BSD
MIPS (RISC/OS)
OSX (Olivetti LSX 30xx)
SunOS3
SunOS4
Ultrix
Also, it uses
-@ld -x -r -o $*.z $@ && mv $*.z $@
on
Concurrent RTU 6.0
and
-ld -r $@ && mv a.out $@
on
"osi - SunOS" (whatever that is)
solbourne

I think other options will do the same on some other systems.


Regards,

Hallvard

>>>>> "Andy" == Andy Dougherty <doughera@lafcol.lafayette.edu> writes:
>>>>> "Phil" == Phillip Moore <wpm@ms.com> writes:

Phil> The default makefile generated by the perl5.001m Configure
Phil> installed libperl.a and most of the perl5 header files into
Phil> lib/perl5/CORE. This is a substantial amount of disk space for
Phil> the multiple platforms we build perl5 on:

Phil> Is it really essential to distribute this?? If I am right, then
Phil> this needs to reside in src/build are, but not necessarily on
Phil> every fileserver we have providing replicated access to perl5.

Andy> If you're sure no one will want to build a new static perl, you
Andy> can safely delete libperl.a.

Well, if I want to build a new static perl, I'll do so in the
development tree. I have one copy of the source, but a multiple
copies of the distributed binaries worldwide. This is the issue --
what is needed in production runtime, and what is a development
utility.

Andy> Keep the headers, though, because they *are* needed for dynamic
Andy> extensions. (They're not too big anyway.)

Hmm. truss and strace would seem to debunk this. I see no real time
access to any of the contents of ..../lib/perl5/CORE when I use any of
the following modules.

Sybase::DBlib
Tk
POSIX

I.e. a crude test was:

truss perl5 -e 'use Tk' 2>&1 | egrep CORE

I'd have to disagree. I can't see any access to the CORE directory by
perl5 during runtime. I've verified this on SunOS 4.1.3 and 5.4. So,
I'd have to disagree. You don't need CORE runtime at all.

Phil

>>>>> "Andy" == Andy Dougherty <doughera@lafcol.lafayette.edu> writes:
>>>>> "Phil" == Phillip Moore <wpm@ms.com> writes:

Phil> Hmm. truss and strace would seem to debunk this.

Andy> Sorry. I meant to say they are needed for *building* dynamic
Andy> extensions.

Ah.... well, I point the build procedure for dynamic modules at the
perl5 source tree, but then, we're centralized, so this is feasible.

Given the significant space savings, particularly in a heterogenous
environment, this should probably be an option one could specify in
Configure.

>>>>> "Andreas" == Andreas Koenig <k@anna.mind.de> writes:

Andreas> Try grep CORE /usr/local/lib/perl5/ExtUtils/MakeMaker.pm

Again -- not used

Andreas> Maybe you're not aware, that any user in any directory is
Andreas> able to compile any extension *without* having access to the
Andreas> source tree -- which really takes up a considerable amount of
Andreas> diskspace.

Our perl5 source tree is available in AFS globally, so anyone and
everyone has access to it. I am going to keep a copy of the compiled
CORE stuff online in the src tree for just this purpose. ONE copy,
not close to 60.

Andreas> If you want to save diskspace, tar and compress your perl
Andreas> source and leave CORE as it is. Just a hint, not an
Andreas> imperative :)

That's not the issue I am dealing with. The source tree is nothing
compared to the size of the distribution copy times 20 AFS cells times
3 replica sites. If the default installation includes 15MB of files I
don't need to replicate globally, then i am not going to install them.

Production end users do not compile modules, developers do, and they
can suffer with a single copy of the source tree.

Phil

>>>>> "Andy" == Andy Dougherty <doughera@lafcol.lafayette.edu> writes:
>>>>> "Phil" == Phillip Moore <wpm@ms.com> writes:

Phil> Given the significant space savings, particularly in a
Phil> heterogenous environment, this should probably be an option one
Phil> could specify in Configure.

Andy> I have no objection to this if anyone wants to submit a patch.

Looks pretty trivial. I'll see if I can't put this together. Default
answer obviously is yes.

I also want to make installation of the pod files themselves optional,
and make some changes such that the html files get installed as well.
This means pod2html needs an option to open the output files somewhere
other than the same place the sources are.

I am a bit suprised that noone has tackled this before, as it seems
pretty easy. Am I about to step into a pile of something I'd rather
not?? Anyone been there, done that...

Phil

>>>>> "phillip" == Phillip Moore <wpm@morgan.com> writes:

>>>>> "me" == Andreas Koenig <k@anna.mind.de> writes:
me> Try grep CORE /usr/local/lib/perl5/ExtUtils/MakeMaker.pm

phillip> Again -- not used

If you don't count developers as users, as your last paragraph seems
to imply, then you're right.

me> Maybe you're not aware, that any user in any directory is
me> able to compile any extension *without* having access to the
me> source tree -- which really takes up a considerable amount of
me> diskspace.

phillip> Our perl5 source tree is available in AFS globally, so anyone and
phillip> everyone has access to it. I am going to keep a copy of the compiled
phillip> CORE stuff online in the src tree for just this purpose. ONE copy,
phillip> not close to 60.

As Andy has already stated, you can safely delete the libperl.a
file. What is left is 261057 bytes headerfiles. 261057 * 60 =
15663420, nothing to argue about.

me> If you want to save diskspace, tar and compress your perl
me> source and leave CORE as it is. Just a hint, not an
me> imperative :)

phillip> That's not the issue I am dealing with. The source tree is nothing
phillip> compared to the size of the distribution copy times 20 AFS cells times
phillip> 3 replica sites. If the default installation includes 15MB of files I
phillip> don't need to replicate globally, then i am not going to install them.

Why don't you make the installed library tree globally available? It
is definitely cross-platform compatible. All you need are different
binaries for each platform and the same path name to
/...../lib/perl5. If the same path name is not feasible for you, look
at the sitelib variable in Configure. That compiles a longer path for
@INC into your perl binary.

Ok, most probably the global tree is slower than the replicated one,
right? Again use the sitelib variable: install into a place that is
later readable as
/the/one/and/only/true/complete/perl5/installation/directory, make it
globally available and append this directory together with the
corresponding architecture specific directory to @INC via
sitelib. Replicate only the 15 modules you need for your
application. Delete the source tree.

The reason why I'm arguing here is that I consider the perl source
tree broken. Not seriously broken -- apparently it works :-) -- but
unusable for cross-platform development. Watch out for Config.pm,
*.so, *.bs, *.a, etc. that fill the lib/ tree with architecture
specific stuff.

I'm working on MM again these days, and I might even clean this up a
little. But you should know, that I would _currently_ not recommend
your approach.

phillip> Production end users do not compile modules, developers do, and they
phillip> can suffer with a single copy of the source tree.

No comment.

phillip> Phil


andreas

On Thu, 19 Oct 1995, Andreas Koenig wrote:

> The reason why I'm arguing here is that I consider the perl source
> tree broken. Not seriously broken -- apparently it works :-) -- but
> unusable for cross-platform development. Watch out for Config.pm,
> *.so, *.bs, *.a, etc. that fill the lib/ tree with architecture
> specific stuff.

It's certainly true that the perl source tree would be cleaner if it
had separate build library directories for the arch-independent and
arch-dependent stuff. Andreas has done a very nice job handling all that
for extensions in MakeMaker.

It's also apparently true that GNU packages typically support cross
platform building more easily than perl does.

If someone feels strongly enough about any of these issues to
submit a patch, I'm sure others would welcome the contribution.

Andy Dougherty doughera@lafcol.lafayette.edu
--
To subscribe or unsubscribe, send your request (subscribe, unsubscribe)
in the BODY of a message to perl5-porters-request@africa.nicoh.com.

On Thu, 19 Oct 1995, Andreas Koenig wrote:

> The reason why I'm arguing here is that I consider the perl source
> tree broken. Not seriously broken -- apparently it works :-) -- but
> unusable for cross-platform development. Watch out for Config.pm,
> *.so, *.bs, *.a, etc. that fill the lib/ tree with architecture
> specific stuff.

It's certainly true that the perl source tree would be cleaner if it
had separate build library directories for the arch-independent and
arch-dependent stuff. Andreas has done a very nice job handling all that
for extensions in MakeMaker.

It's also apparently true that GNU packages typically support cross
platform building more easily than perl does.

If someone feels strongly enough about any of these issues to
submit a patch, I'm sure others would welcome the contribution.

Andy Dougherty doughera@lafcol.lafayette.edu
--
To subscribe or unsubscribe, send your request (subscribe, unsubscribe)
in the BODY of a message to perl5-porters-request@africa.nicoh.com.

On Thu, 19 Oct 1995, Andreas Koenig wrote:

> The reason why I'm arguing here is that I consider the perl source
> tree broken. Not seriously broken -- apparently it works :-) -- but
> unusable for cross-platform development. Watch out for Config.pm,
> *.so, *.bs, *.a, etc. that fill the lib/ tree with architecture
> specific stuff.

It's certainly true that the perl source tree would be cleaner if it
had separate build library directories for the arch-independent and
arch-dependent stuff. Andreas has done a very nice job handling all that
for extensions in MakeMaker.

It's also apparently true that GNU packages typically support cross
platform building more easily than perl does.

If someone feels strongly enough about any of these issues to
submit a patch, I'm sure others would welcome the contribution.

Andy Dougherty doughera@lafcol.lafayette.edu
--
To subscribe or unsubscribe, send your request (subscribe, unsubscribe)
in the BODY of a message to perl5-porters-request@africa.nicoh.com.

In <9510181808.AA06589@sas1-f0.morgan.com>
On Wed, 18 Oct 95 14:08:50 EDT
<wpm@morgan.com> writes:
>>>>>> "Andy" == Andy Dougherty <doughera@lafcol.lafayette.edu> writes:
>>>>>> "Phil" == Phillip Moore <wpm@ms.com> writes:
>
>Phil> Hmm. truss and strace would seem to debunk this.
>
>Andy> Sorry. I meant to say they are needed for *building* dynamic
>Andy> extensions.
>
>Ah.... well, I point the build procedure for dynamic modules at the
>perl5 source tree, but then, we're centralized, so this is feasible.

Fair enough if you know what you are doing, but you would be amazed
at number of Tk-won't-build messages I get from folks that do that,
using a *relative* pathname and wondering why Tk's sub-extensions
fail.

Putting the these files in CORE was a major win for those of us
that support extensions.

I suggest that you that know, and care, do rm -r .../CORE and leave
install process 'safe' for the less experienced.

>
>Given the significant space savings, particularly in a heterogenous
>environment, this should probably be an option one could specify in
>Configure.

One more question to ask the XX-won't build folk...

In <9510181808.AA06589@sas1-f0.morgan.com>
On Wed, 18 Oct 95 14:08:50 EDT
<wpm@morgan.com> writes:
>>>>>> "Andy" == Andy Dougherty <doughera@lafcol.lafayette.edu> writes:
>>>>>> "Phil" == Phillip Moore <wpm@ms.com> writes:
>
>Phil> Hmm. truss and strace would seem to debunk this.
>
>Andy> Sorry. I meant to say they are needed for *building* dynamic
>Andy> extensions.
>
>Ah.... well, I point the build procedure for dynamic modules at the
>perl5 source tree, but then, we're centralized, so this is feasible.

Fair enough if you know what you are doing, but you would be amazed
at number of Tk-won't-build messages I get from folks that do that,
using a *relative* pathname and wondering why Tk's sub-extensions
fail.

Putting the these files in CORE was a major win for those of us
that support extensions.

I suggest that you that know, and care, do rm -r .../CORE and leave
install process 'safe' for the less experienced.

>
>Given the significant space savings, particularly in a heterogenous
>environment, this should probably be an option one could specify in
>Configure.

One more question to ask the XX-won't build folk...

In <9510181808.AA06589@sas1-f0.morgan.com>
On Wed, 18 Oct 95 14:08:50 EDT
<wpm@morgan.com> writes:
>>>>>> "Andy" == Andy Dougherty <doughera@lafcol.lafayette.edu> writes:
>>>>>> "Phil" == Phillip Moore <wpm@ms.com> writes:
>
>Phil> Hmm. truss and strace would seem to debunk this.
>
>Andy> Sorry. I meant to say they are needed for *building* dynamic
>Andy> extensions.
>
>Ah.... well, I point the build procedure for dynamic modules at the
>perl5 source tree, but then, we're centralized, so this is feasible.

Fair enough if you know what you are doing, but you would be amazed
at number of Tk-won't-build messages I get from folks that do that,
using a *relative* pathname and wondering why Tk's sub-extensions
fail.

Putting the these files in CORE was a major win for those of us
that support extensions.

I suggest that you that know, and care, do rm -r .../CORE and leave
install process 'safe' for the less experienced.

>
>Given the significant space savings, particularly in a heterogenous
>environment, this should probably be an option one could specify in
>Configure.

One more question to ask the XX-won't build folk...

nick> In <9510191556.AA29231@sas1-f0.morgan.com>
nick> On Thu, 19 Oct 95 11:56:29 EDT
nick> <wpm@morgan.com> writes:
>>
>> I don't perform the Configure/make/make install procedures in the
>> perl5 source tree, but rather in a shadow tree which contains nothing
>> but symlinks to the actual sources. This allos me to perform the
>> compile in parallel on the six(6) platforms we have that I care about.
>> The sources aren't touched.

nick> Same here for my platforms, my link trees are build from
nick> the MANIFEST(s).

This is most easily fixed for extensions. Not so easy for the perl
source. You should have told me. Will be fixed for extensions in the
next MakeMaker. I try to do my best for the perl source also.

andreas

Since I soon need to install perl5.001m (under AFS) for six to eight
platforms, I thought I'd take a look at this. As it turns out, I think
Configure/installperl is pretty close. What I see missing:

1) Configure probably needs an "installprefix" variable. My best
guess is that people generally want to keep the same relative
structure, but under AFS they want to specify a different prefix
for the "real" path to the executables. In my particular case, I
want perl to think everything is under /usr/local, but have it
install under /afs/.eos.ncsu.edu/contrib/perl. Currently, I either
have to go thru Configure manually (a pain), or specify all six
"install*" variables individually. I'd really like to just say:

Configure -des -Dprefix=/usr/local \
-Dinstallprefix=/afs/.eos.ncsu.edu/contrib/perl

and have all the "install*" variables "do the right thing".

2) Since the *.h files are architecture-independent and the libperl*.a
libs are architecture-dependent, the install should probably be:

*.h -> $installprivlib/common/CORE, and
libperl*.a -> $installarchlib/CORE

with MakeMaker adjusted appropriately. The "common" pseudo-arch
name might need changing, but something needs to be there, or
people might get CORE/ confused with the "CORE::" package.

These two changes would certainly fix my AFS woes, and I think would
go a long way to helping most users that need to maintain many
simultaneous architectures.

If someone would tell me how to have metadist generate the Configure
for perl, I'd be happy to try and generate a patch for the above two
problems (assuming they're not going to upset anyone :-).


William

>>>>> "Andy" == Andy Dougherty <doughera@lafcol.lafayette.edu> writes:

Andy> It's certainly true that the perl source tree would be cleaner
Andy> if it had separate build library directories for the
Andy> arch-independent and arch-dependent stuff. Andreas has done a
Andy> very nice job handling all that for extensions in MakeMaker.

Given that the overwhelming majority of packages on the net have NO
support for this built into their native makefiles, and when they do,
they do it wrong, like many others I've had to solve the general
problem on my own.

I don't perform the Configure/make/make install procedures in the
perl5 source tree, but rather in a shadow tree which contains nothing
but symlinks to the actual sources. This allos me to perform the
compile in parallel on the six(6) platforms we have that I care about.
The sources aren't touched.

I don't think this is rocket science, and it is far simpler than
trying to fix everyones broken Makefiles.

Andy> It's also apparently true that GNU packages typically support
Andy> cross platform building more easily than perl does.

Better than most, I will certainly agree.

Phil

On Thu, 19 Oct 1995, William Setzer wrote:

> Since I soon need to install perl5.001m (under AFS) for six to eight
> platforms, I thought I'd take a look at this. As it turns out, I think
> Configure/installperl is pretty close. What I see missing:
>
> 1) Configure probably needs an "installprefix" variable.

Hmm. Looks familiar. Have you read my recently-posted INSTALL file patches?
Here's one of the new sections:

+ =head2 Changing the installation directory
[ . . . ]
+ This section describes how to do this. Someday, Configure may support
+ an option C<-Dinstallprefix=/foo> to simplify this.
+
+ =head2 Creating an installable tar archive


> 2) Since the *.h files are architecture-independent

except, of course, config.h. The rest are architecture-independent.

Andy Dougherty doughera@lafcol.lafayette.edu
--
To subscribe or unsubscribe, send your request (subscribe, unsubscribe)
in the BODY of a message to perl5-porters-request@africa.nicoh.com.

In <9510191556.AA29231@sas1-f0.morgan.com>
On Thu, 19 Oct 95 11:56:29 EDT
<wpm@morgan.com> writes:
>
>I don't perform the Configure/make/make install procedures in the
>perl5 source tree, but rather in a shadow tree which contains nothing
>but symlinks to the actual sources. This allos me to perform the
>compile in parallel on the six(6) platforms we have that I care about.
>The sources aren't touched.

Same here for my platforms, my link trees are build from
the MANIFEST(s).

> From: William Setzer <setzer@guest3.math.ncsu.edu>
>
> 2) Since the *.h files are architecture-independent and the libperl*.a
> libs are architecture-dependent, the install should probably be:
>
> *.h -> $installprivlib/common/CORE, and
> libperl*.a -> $installarchlib/CORE
>
> with MakeMaker adjusted appropriately. The "common" pseudo-arch
> name might need changing, but something needs to be there, or
> people might get CORE/ confused with the "CORE::" package.

I think I was the one who implemented support for copying these
files to .../CORE as part of MakeMaker development pre 5.001.

I thought about putting the headers into privlib instead of archlib
but rejected it. It is _not_ a good idea.

There are two issues here: architecture independance and
version independance.

I believe that all the header files except config.h are architecture
independent. config.h is obviously architecture specific and so must
be installed into archlib.

The other header files are not architecture specific but they _are_
version specific.

If you install a common privlib for multiple architectures and put the
other header files there you are forcing yourself to install a new
version of perl simultaneously for all architectures.

Remember that the header files define the interface to the libperl.a.
and that interface usually changes between versions. Installing a new
perl version for one architecture will mean that building extensions
for others will probably fail in very subtle ways.

On my system libperl.a+config.h is ~985Kb and other headers are ~257Kb.
I think the risks outweigh the benefits.

If you _really_ want to push it I'd suggest doing this:

libperl*.a -> $installarchlib/CORE
config.h -> $installarchlib/CORE
*.h (others) -> $installprivlib/5.001/CORE
^^^^^

and making the corresponding changes in MakeMaker.

But I don't think it's worth it.

(Actually, there is no easy way to get the string '5.001' from config.sh.
You've got baserev='5.0' and patchlevel='1'. It would be handy to have
the complete '5.001' available.)

Tim.