Ticket #735 (closed patch: fixed)

Opened 5 years ago

Last modified 4 years ago

path for installed header files

Reported by: gerd Owned by: jkeenan
Priority: normal Milestone:
Component: install Version: 1.2.0
Severity: medium Keywords:
Cc: gerd Language:
Patch status: applied Platform:

Description

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

Attachments

inst_files.patch Download (1.2 KB) - added by gerd 5 years ago.
patch for tools/dev/install_files.pl and tools/dev/install_dev_files.pl
parrot_pc.in.patch Download (374 bytes) - added by gerd 5 years ago.
generated with: diff -u config…

Change History

Changed 5 years ago by gerd

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

follow-up: ↓ 3   Changed 5 years ago by 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.

  Changed 5 years ago by jkeenan

  • summary changed from path fo installed header files to path for installed header files

in reply to: ↑ 1 ; follow-up: ↓ 4   Changed 5 years ago by 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

in reply to: ↑ 3   Changed 5 years ago by 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.

follow-up: ↓ 6   Changed 5 years ago by 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.

in reply to: ↑ 5   Changed 5 years ago by 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

follow-up: ↓ 8   Changed 5 years ago by NotFound

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

in reply to: ↑ 7   Changed 5 years ago by 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.

Changed 5 years ago by gerd

generated with: diff -u config...

  Changed 5 years ago by 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

  Changed 5 years ago by 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.

  Changed 5 years ago by 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.

  Changed 4 years ago by jkeenan

  • owner set to jkeenan
  • patch set to applied

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

  Changed 4 years ago by jkeenan

  • status changed from new to closed
  • resolution set to fixed
Note: See TracTickets for help on using tickets.