path for installed header files

[gerd]

This patch changes the path for installed header files und the pkgconfig file.

from: /usr/lib/pkgconfig/parrot/1.2.0/parrot.pc to: /usr/lib/pkgconfig/parrot.pc

from: /usr/include/parrot/1.2.0/parrot/... to: /usr/include/parrot/...

from: /usr/include/parrot/1.2.0/pmc/... to: /usr/include/pmc/...

I tested the patch under Fedora. Also building rpms works with this patch. The patch makes the path conform to the docs/embed.pod documentation.

Gerd Pokorra

[gerd]

patch for tools/dev/install_files.pl and tools/dev/install_dev_files.pl

[doughera]

The current behavior may be consistent with the embed.pod documentation, but it may be that the documentation is in error. pdd30 does not specify where the installed C include files are to go.

This patch would make it harder to maintain two separate installed versions of parrot. It is also inconsistent with the lib/ directory layout, which still does have a version-specific part.

[gerd]

Replying to doughera:

The current behavior may be consistent with the embed.pod documentation, but it may be that the documentation is in error. pdd30 does not specify where the installed C include files are to go. This patch would make it harder to maintain two separate installed versions of parrot. It is also inconsistent with the lib/ directory layout, which still does have a version-specific part.

I do not agree. At least the pkgconfig-path should be be changed in the file parrot_files.pl. ( $filehash->{DestDirs} = ['pkgconfig', $parrotdir]; ->

$filehash->{DestDirs} = pkgconfig?; )

In other respects it is a reason for rejecting Parrot as a package in a linux distribution.

This is for installing files on a system and the standard is to have only one version installed of a software and to make updates. I hope the header files of Parrot will not be changed so much. Other software with header files installed under /usr/include do not use version numbers. But if Parrot want to use version numbers in the path of header files 'pkg-config --cflags parrot' should provide '-I/usr/include/parrot/<VERSION>' I think it is not nice and it is better to leave version numbers out in the path of header files (and pdd30.pod will be changed according to that :-) )

Gerd

[doughera]

Replying to gerd:

Replying to doughera:

This patch would make it harder to maintain two separate installed versions of parrot. It is also inconsistent with the lib/ directory layout, which still does have a version-specific part.

This is for installing files on a system and the standard is to have only one version installed of a software and to make updates.

Except your patch affected all installs, not just ones intended for distribution via packages (which is what I gather you mean by "installing files on a system").

I hope the header files of Parrot will not be changed so much.

Experience in perl 5 is that they do change. Looking at other projects (python, tcl) suggests perl 5's experience is not unique.

Other software with header files installed under /usr/include do not use version numbers.

That's simply not true. For example, on a Debian "lenny" system in /usr/include, I see directories for python1.5, python2.1, python2.2, python2.4, and python2.5. Under /usr/include/c++, I see separate directories for 3.2, 3.3, 4.1.2, 4.1.3, and 4.3.

More generally, for something such as parrot that is intended to provide an infrastructure, it is unreasonable to expect all applications to simultaneously upgrade every time a new, incompatible version of parrot appears.

But if Parrot want to use version numbers in the path of header files 'pkg-config --cflags parrot' should provide '-I/usr/include/parrot/<VERSION>'

Yes, I agree that pkg-config should tell you the correct cflags invocation. Unfortunately, since the C files have things like #include <parrot/embed.h> , that means the directory tree would include things like /usr/include/parrot/<VERSION>/parrot/embed.h. I agree that's ugly.

My main points are 2:

1. It should be possible (and relatively easy) to maintain more than one installed version of parrot.

2. pdd30 ought to address the issue explicitly, bearing in mind both where the files will be installed and how they will be used.

[NotFound]

We talked about the include directory some time ago, bit nothing has been decided.

We can set the include directory (-I or equivalent option) using the full path, and use just #include <embed.h> However, the names of several files are too generic (string.h !), we must prefix them with parrot_ or something to avoid conflicts if we go that way.

[bacek]

Replying to NotFound:

We can set the include directory (-I or equivalent option) using the full path, and use just #include <embed.h> However, the names of several files are too generic (string.h !), we must prefix them with parrot_ or something to avoid conflicts if we go that way.

Classical solution is '#include <parrot/string.h>' in public headers and '#include "parrot/string.h"' in private c/h files. Then external programs will always built with system-installed parrot, during development we will use headers from build-dir.

-- Bacek

[NotFound]

Yes, but that way does not solve the need for a /usr/include/parrot/<VERSION>/parrot/ directory.

[bacek]

Replying to NotFound:

Yes, but that way does not solve the need for a /usr/include/parrot/<VERSION>/parrot/ directory.

I don't see any particular bad thing having this directory. It's only one way to support multiple installed parrots on single box. We can rename "parrot/<VERSION>" to "parrot<VERSION>" though.

[gerd]

generated with: diff -u config...

[gerd]

I do not want to start this discussion again. Because I think the design decision is made. It looks like that the installed header files should go to /usr/include/parrot/<VERSION>/parrot/...

So the new little patch it to support this for 'pkg-config --cflags'.

By the way here an alternative for the command line:

-Iparrot_config includedir versiondir

[allison]

Yes, the version numbers in paths (even include file paths) are by design, and aren't changing. It's a common strategy for packaging systems that want to allow multiple versions to be installed at the same time (Python on Ubuntu is a good example). However, we could potentially add a --version-prefix option that allows the version directory prefix to be altered or eliminated entirely (set to an empty string), for the sake of packaging systems that don't want it.

I also dislike the redundancy of /usr/include/parrot/<VERSION>/parrot/..., and would prefer to flatten out the #include <parrot/string.h>, etc to just #include <parrot_string.h>. There was some discussion about this when we first added versioned directories, but no change so far, largely because it's just one small question in a larger header file cleanup needed. It's not urgent, just a coding standards question.

The simplified parrot.pc template patch is good.

[gerd]

I also dislike the redundancy path of header files and I think an installed production version and a svn development version of Parrot are sufficient. But there are enough people who like the possibility to have different installed versions. So a --version-prefix option would be nice. But on the other side there may be a disadvantage. May be there is a lot of maintenance to do to take care that some files and documentation have to change the contents if the switch is set or not. Maintain files that will be generated at the configuration will make more work I think.

[jkeenan]

It appears that Gerd applied the patch last March.

6f8d7b8c config/gen/makefiles/parrot_pc.in 
  (Gerd Pokorra         2010-03-12 13:35:35 +0000 10) 
  Cflags: -I${includedir}@versiondir@

But the ticket was never closed. Doing so.

kid51