#735: path for installed header files
-------------------+--------------------------------------------------------
Reporter: gerd | Type: patch
Status: new | Priority: normal
Milestone: | Component: install
Version: 1.2.0 | Severity: medium
Keywords: | Lang:
Patch: | Platform:
-------------------+--------------------------------------------------------
Comment(by doughera):
Replying to [comment:3 gerd]:
> Replying to [comment:1 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.
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/735#comment:4>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
