Re: Including windows-binary files for cross compiling into package

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2009-11-03 at 12:56 +0000, Richard W.M. Jones wrote:
> On Mon, Oct 26, 2009 at 07:42:56PM +0100, Joost van der Sluis wrote:
> > On Mon, 2009-10-26 at 11:15 -0700, Roland McGrath wrote:
> > > If it's true cross support, then that should be a noarch package and the
> > > file names it uses should not depend on %{_lib} that way.  
> > > Arguably it even belongs in %{_sharedir}, since it is fixed binary content
> > > across all host machines.
> > 
> > Those files are not architecture independent. They are somewhat similar
> > to .o files. They contain the run time library for the language,
> > compiled to native windows object files. If you want to compile your own
> > program with them afterwards, they are linked together into a windows
> > executable.
> > 
> > You could argue that they should belong in a -devel package. But since
> > this package is a compiler, we decided not to split it up into a devel
> > package and a non-devel package. As that would be pointless, as one will
> > not work without the other.
> 
> Sorry, I'm late on this one.  Yes the files *are* arch independent
> from the point of view of the host, so they should be noarch.

That's true.

> Anyway you may find the Fedora MinGW packaging guidelines to be
> helpful, and it would be useful to make your package compatible with
> the other ones, even if that deviates from upstream a little bit.

A little bit? Did you read my other mail on the subject:

"That's an idea, but then we would be incompatible with upstream. I can
try to patch the configuration files of fpc so that it searches for
these binaries in /usr/x86_64-pc-fpc/sys-root/fpc/lib. But I prefer the
'standard' location. Also because other packages based in fpc relay on
that.

And what I've read here is that this path is chosen because mingw needs
a root filesystem location. Fpc does not need that, so I think I keep
the default locations, if that's ok."

The thing is that fpc does not need a complete build-environment or
something like that. It's just the compiler, one executable. Nothing
more. And offcourse the compiled object-files, we are discussing the
locations of these files only.

I think I can patch the compiler and it's configuration files. But I
think it's not really doable to patch Lazarus, a freepacal-ide, to use
these paths. 

> We've also packaged some things, such as the OCaml cross-compiler,
> which sound very similar to the Pascal case you describe.

I can have a look. 

>   http://fedoraproject.org/wiki/Packaging/MinGW

Another thing, the MinGW packaging guidelines needs the packages to have
a 'MinGw' prefix, not suffix.

My example used a suffix, like 'fpc-win32'. Do you think I should use
'win32-fpc' instead? Again: this sounds logical when you have a complete
build-environment or something like that. But in this case I think
'fpc-win32' is more logical.

Joost



-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux