kicad-developers team mailing list archive

[Alain Portal <alain.portal@...>]

Hi,

This is funny I read this post as I stopped to read the thread because I 
didn't understand what it was said in the thread, and because my english.
But, I saw my name ;-)

Le Jeudi 25 Mars 2010 09:00:56, vous avez écrit :
> On 25/03/10 06:36, jean-pierre.charras@... wrote:
> > Dick Hollenbeck a écrit :
> >> Good point. But I was thinking that Jean Pierre was statically linking
> >> in the wxWidgets libraries to the apps. If not, I don't see how he has
> >> gotten as far as he has with these "universal x86 linux binaries".
> > 
> > Of course, wxWidgets is linked statically (and it is also patched)
> > Preinstalled wxWidgets versions (when exist) never work.
> > I tried to link statically libsupc++ (under Ubuntu 9.10 and GCC 4.4),
> > and I was lucky! it worked:
> > 1 - Locate libsupc++.a and add it to libs list
> > 2 - use gcc instead of g++ to call the linker.
> > 
> > Note: I used my old makefiles to test that, because it was more easier
> > to quickly test different link options.
> > 
> > I now must test binaries under different Linux distribs.
> 
> As a matter of interest I presume kicad is thinking of making the binaries
> available in simple tar form rather than packages as RPM or DEB packages ?
> I wonder how many users install from this type of package these days. I
> certainly haven't for many years.

As a general rule, upstream should never provide binary tarball for his 
program, for Linux. Only a source tarball that the user will be able to 
compile.
So, of cource, no statically linked libraries.

> I wonder if it would be better to more closely work with the Debian/Ubuntu
> and Fedora/Centos packagers and help formulate standard *.spec etc files
> for kicad as part of the source tree ?

I'm not sure this is a good idea, as an example for rpm like distributions 
(Fedora, Redhat, Mandriva, Opensuse, Centos, etc.), to put spec files in the 
source tree because distibutions don't use the same macros (and use distro 
specific macros) in the spec files.

> This will make it easier for the
> packagers to package new releases and put it into the distribution's
> testing or main repositories.

What will make easier for the packagers to packages new release is that 
upstream accept some patches packagers used to package the current version.

When I got the last version (on svn repository, not the tarball), I succeded 
to compile it on my system.
When I tried to build a Fedora rpm on my system, I succeded.
But when I submitted my work on Fedora Build System, the built failed :-(
Because a problem with linking the kbool library (which, in my opinion, don't 
have to be in the kicad source, it was probably the source of the problem).

As I wasn't able to fix this problem, I asked for help on the Fedora 
developpers list, and someboby provided me the patch I used to build the 
current Fedora Kicad rpm

> I note that someone was on this forum (Alain Portal?)

That me :-D

> recently asking for
> help to package for Fedora, Redhat EL5/Centos5 recently.

On this list, it was for Centos (Fedora EPEL (Extras Packages for Entreprise 
Linux)), and unfortunately, I got not solution :-(
I sad to not be able to offer the kicad new version for Centos users.

> They tend to
> know the particular distributions better and probably can help provide
> the basic testing for binary packages on the core used platforms out there.

As a general rule, packagers test the binaries they built, not binaries built 
by someone.

> For the less used/maintained Linux distributions maybe kicad could produce
> and distribute a RPM and DEB package source package that can
> then be easily built by users (as well as the source in tar form) ? Also
> it would be possible to produce a generic binary RPM and DEB with
> statically linked libraries etc if needed.

For the less used/maintained Linux distributions, users have to be able to 
compile kicad from source tarball, not to install a binary...

Regards,
Alain
-- 
Les pages de manuel Linux en français
http://manpagesfr.free.fr
 --nextPart4308553.XLqBnfeBPm Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.

[Attachment content not displayed.] --nextPart4308553.XLqBnfeBPm--