[wx-dev] RFD: Debian packages for wx 3.0
Vadim Zeitlin
Hello,
One of the things which needs to be done in preparation for 2.9.0 release
is fixing Debian[-based system] package building. We could just do the
strict minimum and simply remove the current hacks dealing with Unicode and
ANSI versions and keep the rest like it is now. However I'd like to do
more, if possible, and simplify the 1000+-lines monstrosity that is
debian/rules to be easier to maintain by mere mortals. In fact I'd like to
totally rewrite this file as a lot of things have changed in wx since 2.4
(or 2.2?) when it was written but the file was never updated to e.g. use
the libwxbase library created as part of a normal build instead of using a
separate configure run and make. We also need to change the docs package
creation completely with the switch to doxygen and so on. So, to repeat, I
think it's time to simplify the existing mess, especially as it's clear
that we'll have to maintain Debian packages ourselves for the foreseeable
future because of well-known issue with the official maintainer. Luckily,
Devid Filoni, one of wx maintainers for Ubuntu, is ready to help us with
this rewrite (thanks in advance Devid!). But we need to decide how do we
want to package wx for Debian systems before asking him to do it.
The first and most important thing I'd like to change is to split wx and
wxPython packages generation. This will, of course, need Robin's approval
(for which I'm waiting eagerly :-) but it really doesn't make much sense to
always build wxPython and wx packages by default and have a separate hack
to build just the C++ packages as we do now. Logically, the packages are
independent and wxPython ones should simply depend on the C++ ones. And
while it probably doesn't matter much from practical point of view because
the existing Debian maintainer will block any development anyhow, I should
also mention that I was asked to split these packages by several people
from Debian. I hope this can be accepted and so I'll only speak about the
C++ packages below and will leave the specification of what wxPython
packages we should have (possibly the same as now, of course) to Robin.
Second potentially controversial proposal is to separate libwxmsw packages
from libwxgtk ones too. Of course, libwxmsw packages may be useful but I'm
not sure if they're useful enough for us to maintain them and if we do have
the resources to do it I'd rather have a generic debian/rules which can
deal with any port (GTK, X11, DFB and, well, MSW) than lumping them
together with GTK packages arbitrarily. But for now we could start with
having a simple and clean debian/rules for just wxGTK and generalize this
later. What do you think?
Next question is about the granularity of the libraries packages. We can
have:
a) A single libwxgtk package including all wxGTK and wxBase libraries
b) Separate libwxgtk and libwxbase packages just as now
c) Multiple libwxgtk-{core,adv,html,aui,...} and libwxbase packages
I find the solution (c) to be rather attractive because it's internally
consistent (e.g. it treats libwxbase in the same way as all the other
libraries) and also would allow us to introduce dependencies for only some
packages, e.g. libwxgtk-html could, in theory, depend on Gecko while still
allowing installing all the other libraries without Gecko dependency (a
more realistic example would probably be some dependency of libwxgtk-media).
It also makes adding new libraries somewhat simpler.
OTOH I don't know if it's worth the extra trouble, especially if we need
to provide -dev and/or -dbg versions for every library. What do you think?
Speaking of -dbg packages, I think the plan is to make wx builds with and
without __WXDEBUG__ ABI-compatible in wx3. If we do this, I think we should
build wx with -O (and without -g?) but with __WXDEBUG__ defined by default.
This would hopefully make it unnecessary to provide separate -dbg packages
for each library although it would still be nice to have debug symbols in a
separate package (hmm, this means building with -g though). I.e. it would
make sense to do the same thing (whatever this thing is, I'm a bit hazy
about the details) as packages of GTK+ itself do.
The most complicated question is one of libwx-dev package(s). Currently we
have libwxbase-dev and libwxgtk-dev. We clearly don't want to have
libwxgtk-{core,adv,html,...}-dev so this is not really compatible with the
proposal (c) above. But in fact I don't even like the current separation
between libwxbase-dev and libwxgtk-dev. The -dev packages don't contain
much, in fact: just the (build-specific) wx-config and setup.h and the .so
link. So I'd like to propose to have the libwx-headers package (the name
seems better/more consistent with other libraries than the current
wx-headers) and one and only one libwx-dev package which would contain
wx-config which could be used for both base and GUI applications
development (using "wx-config --libs base" for the former) as well as the
current contents of wx-common, i.e. wxrc and wxwin.m4 (having a separate
package just for this is really not worth it IMO). What do you think of
this approach?
Finally, we probably should keep wx-doc and wx-examples packages as
they're although we could also possibly combine them. The only drawback of
this is that this would make wx-doc package depend on libwx-dev one. And we
should keep wx-i18n (except probably renamed to libwx-i18n) package too as
this seems to be the Debian convention.
To summarize, I propose to have the following packages (not counting
wxPython ones, again, I hope Robin can post what he'd like to do with them,
even if it's just to say that current packages are fine and should be kept
without changes):
1. Library packages:
- libwxbase3.0 and libwxbase-{net,xml}3.0
- libwxgtk-{adv,aui,core,gl,html,media,qa,richtext,src,xrc}3.0
2. A single debug package libwx3.0-dbg containing symbols for all of the
above.
3. Development packages:
- libwx3.0-headers containing all headers (excluding setup.h)
- libwx3.0-dev containing wx-config, wxrc and setup.h
4. Documentation packages:
- libwx3.0-doc containing HTML docs (I think one format is enough)
- libwx3.0-examples containing all the samples and maybe demos (unless we
prefer to include example in the doc package)
5. I18n package libwx3.0-i18n
Concerning the Debian files themselves I'd like to be able to specify the
port we're building packages for ("gtk", "msw", "dfb", ...) when building
them. I don't know if there is any standard about doing this but I hope it
can be done -- any feedback from people more familiar with Debian packages
would be welcome.
Of course, any feedback concerning the above packages structure would be
most welcome as well.
TIA!
VZ
Stefa...@t-online.de
> 1. Library packages:
> - libwxbase3.0 and libwxbase-{net,xml}3.0
> - libwxgtk-{adv,aui,core,gl,html,media,qa,richtext,src,xrc}3.0
Thinking of the poor person that might have to install things by
hand, I really dislike to have a dozen separate packages which
need to be installed in the right order to get to the point where
I might be able to start installing the application I originally was
interested in.
Having less packages IMHO clearly simplifies users' life here.
> 2. A single debug package libwx3.0-dbg containing symbols for all of
> the above.
BTW, does anybody have a reference to a nice description on how you
put the debugging symbols into a separate file and how you make use
of it? Or is it something that would be obvious once I upgraded to
gcc-4.x? (Sorry for the OT question...)
> 3. Development packages:
> - libwx3.0-headers containing all headers (excluding setup.h)
> - libwx3.0-dev containing wx-config, wxrc and setup.h
>
> 4. Documentation packages:
> - libwx3.0-doc containing HTML docs (I think one format is enough) -
> libwx3.0-examples containing all the samples and maybe demos (unless
> we prefer to include example in the doc package)
>
> 5. I18n package libwx3.0-i18n
2. to 5. sound good to me, but then I'm not a debian user anyway...
> Concerning the Debian files themselves I'd like to be able to specify
> the port we're building packages for ("gtk", "msw", "dfb", ...) when
> building them. I don't know if there is any standard about doing this
> but I hope it can be done -- any feedback from people more familiar
> with Debian packages would be welcome.
Maybe we would need to split stuff into a common package and into
port-specific pacakges? AFAIR, debian doesn't really like several
packages trying to install the same file(s)...
Regards,
Stefan
Robin Dunn
> Luckily,
> Devid Filoni, one of wx maintainers for Ubuntu, is ready to help us with
> this rewrite (thanks in advance Devid!).
Welcome and thanks from me too! I wish I had more time to devote to
packaging, but it just simply isn't there for me.
> The first and most important thing I'd like to change is to split wx and
> wxPython packages generation. This will, of course, need Robin's approval
> (for which I'm waiting eagerly :-) but it really doesn't make much sense to
> always build wxPython and wx packages by default and have a separate hack
> to build just the C++ packages as we do now. Logically, the packages are
> independent and wxPython ones should simply depend on the C++ ones. And
> while it probably doesn't matter much from practical point of view because
> the existing Debian maintainer will block any development anyhow, I should
> also mention that I was asked to split these packages by several people
> from Debian. I hope this can be accepted and so I'll only speak about the
> C++ packages below and will leave the specification of what wxPython
> packages we should have (possibly the same as now, of course) to Robin.
There are some advantages to keeping them together, mainly related to
being able to do coordinated sub-release releases (i.e. the 4th digit in
the version numbers, 2.8.7.1, 2.8.7.2, etc.) between the official
wxWidgets releases. This lets me release wxPython builds in a more
timely manner that may require fixes in wxWidgets that haven't been
released yet. Of course this can still be done however with the package
generation for wxWidgets and wxPython split, it would just be a little
easier with them combined.
So while I won't oppose the split, I'm not sure yet if I can give it a
full vote until I think more about it or see some more concrete plans.
So call it a +0.5 for now, as long as it is still easy to roll out
incremental subrelease snapshots of wxGTK as needed for wxPython releases.
BTW, not as justification or anything, just FYI, last I checked several
of the RPM based distros have started doing combined wxGTK and wxPython
builds from a single .spec file and using the tarball I produce as part
of wxPython releases.
> Second potentially controversial proposal is to separate libwxmsw packages
> from libwxgtk ones too. Of course, libwxmsw packages may be useful but I'm
> not sure if they're useful enough for us to maintain them and if we do have
> the resources to do it I'd rather have a generic debian/rules which can
> deal with any port (GTK, X11, DFB and, well, MSW) than lumping them
> together with GTK packages arbitrarily. But for now we could start with
> having a simple and clean debian/rules for just wxGTK and generalize this
> later. What do you think?
+1
Ever since I've been running my own apt repository I've never built the
msw packages, and I've never had a request for them neither.
> Next question is about the granularity of the libraries packages. We can
> have:
>
> a) A single libwxgtk package including all wxGTK and wxBase libraries
> b) Separate libwxgtk and libwxbase packages just as now
> c) Multiple libwxgtk-{core,adv,html,aui,...} and libwxbase packages
>
> I find the solution (c) to be rather attractive because it's internally
> consistent (e.g. it treats libwxbase in the same way as all the other
> libraries) and also would allow us to introduce dependencies for only some
> packages, e.g. libwxgtk-html could, in theory, depend on Gecko while still
> allowing installing all the other libraries without Gecko dependency (a
> more realistic example would probably be some dependency of libwxgtk-media).
> It also makes adding new libraries somewhat simpler.
>
> OTOH I don't know if it's worth the extra trouble, especially if we need
> to provide -dev and/or -dbg versions for every library. What do you think?
Another thing to think about for (c) is the packages that use wx. With
(c) they would then have to get much more detailed in listing their
dependencies and it's easily possible that many would either not get it
right, or they would just include all the libs even if they are not
using all of them.
> Speaking of -dbg packages, I think the plan is to make wx builds with and
> without __WXDEBUG__ ABI-compatible in wx3. If we do this, I think we should
> build wx with -O (and without -g?) but with __WXDEBUG__ defined by default.
++1
For the other platforms I already use --enable-optimise and
--enable-debug_flag (and the equivalent on MSW) in order to keep the
wxASSERTs and etc. because they are turned into Python exceptions in
wxPython. Currently the debian/ubuntu packages do not do this and so
developers have to install the -dbg packages to get the same level of
runtime protection that the other platforms get by default.
> This would hopefully make it unnecessary to provide separate -dbg packages
> for each library although it would still be nice to have debug symbols in a
> separate package (hmm, this means building with -g though).
IIRC you can build with -g, make the debug symbols package, and then
strip the binaries before making the lib packages.
> The most complicated question is one of libwx-dev package(s). Currently we
> have libwxbase-dev and libwxgtk-dev. We clearly don't want to have
> libwxgtk-{core,adv,html,...}-dev so this is not really compatible with the
> proposal (c) above. But in fact I don't even like the current separation
> between libwxbase-dev and libwxgtk-dev. The -dev packages don't contain
> much, in fact: just the (build-specific) wx-config and setup.h and the .so
> link. So I'd like to propose to have the libwx-headers package (the name
> seems better/more consistent with other libraries than the current
> wx-headers) and one and only one libwx-dev package which would contain
> wx-config which could be used for both base and GUI applications
> development (using "wx-config --libs base" for the former) as well as the
> current contents of wx-common, i.e. wxrc and wxwin.m4 (having a separate
> package just for this is really not worth it IMO). What do you think of
> this approach?
+1
> To summarize, I propose to have the following packages (not counting
> wxPython ones, again, I hope Robin can post what he'd like to do with them,
> even if it's just to say that current packages are fine and should be kept
> without changes):
Yes, as far as I know the current set of wxPython packages is fine,
although we'll want to drop the addons package in 2.9 since the need for
that one is going away. The only issue for me at the moment is the
question of whether or not to split the generation of wxPython packages
out of wxGTK's build scripts, and I won't oppose that if that is what is
decided.
>
> 1. Library packages:
> - libwxbase3.0 and libwxbase-{net,xml}3.0
> - libwxgtk-{adv,aui,core,gl,html,media,qa,richtext,src,xrc}3.0
>
> 2. A single debug package libwx3.0-dbg containing symbols for all of the
> above.
Do the -dbg packages need to have dependencies on the lib packages?
IOW, will installing libwx3.0-dbg force the installation of all the
libwx* packages?
>
> 3. Development packages:
> - libwx3.0-headers containing all headers (excluding setup.h)
> - libwx3.0-dev containing wx-config, wxrc and setup.h
Is there any need/desire to have an additional dev package containing
the static libraries?
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Vadim Zeitlin
RD> There are some advantages to keeping them together
I do realize this but I think they're compensated by disadvantages of
having to understand both C++ and Python part whenever you modify the files
even if you're interested in only one of them. I.e. I believe the savings
in complexity will be significant enough to compensate for these
advantages.
RD> > Next question is about the granularity of the libraries packages. We can
RD> > have:
RD> >
RD> > a) A single libwxgtk package including all wxGTK and wxBase libraries
RD> > b) Separate libwxgtk and libwxbase packages just as now
RD> > c) Multiple libwxgtk-{core,adv,html,aui,...} and libwxbase packages
RD> >
RD> > I find the solution (c) to be rather attractive
...
RD> Another thing to think about for (c) is the packages that use wx. With
RD> (c) they would then have to get much more detailed in listing their
RD> dependencies and it's easily possible that many would either not get it
RD> right, or they would just include all the libs even if they are not
RD> using all of them.
I believe that dpkg-buildpackage would catch the dependencies on shared
libraries not listed in the package, wouldn't it?
Also, in reply to Stefan, apt-get/aptitude/synaptic/whatever takes care of
dependencies anyhow so it doesn't matter if the package you install has 1
dependency or 10 of them to the final user.
So I still remain in favour of multiple packages because of the extra
flexibility this affords us concerning dependencies. Right now we often
don't want to introduce any big libraries as dependencies but if they were
only used by one sub-library this consideration wouldn't be as important as
now any more with the approach (c).
RD> > Speaking of -dbg packages, I think the plan is to make wx builds with and
RD> > without __WXDEBUG__ ABI-compatible in wx3. If we do this, I think we should
RD> > build wx with -O (and without -g?) but with __WXDEBUG__ defined by default.
RD>
RD> ++1
I guess we should also make this default for configure.
RD> > This would hopefully make it unnecessary to provide separate -dbg packages
RD> > for each library although it would still be nice to have debug symbols in a
RD> > separate package (hmm, this means building with -g though).
RD>
RD> IIRC you can build with -g, make the debug symbols package, and then
RD> strip the binaries before making the lib packages.
Ok, very good.
RD> Yes, as far as I know the current set of wxPython packages is fine,
RD> although we'll want to drop the addons package in 2.9 since the need for
RD> that one is going away. The only issue for me at the moment is the
RD> question of whether or not to split the generation of wxPython packages
RD> out of wxGTK's build scripts, and I won't oppose that if that is what is
RD> decided.
Thanks! Again, I hope that the resulting simplification will make this
worth for you too in long term.
RD> > 1. Library packages:
RD> > - libwxbase3.0 and libwxbase-{net,xml}3.0
RD> > - libwxgtk-{adv,aui,core,gl,html,media,qa,richtext,src,xrc}3.0
RD> >
RD> > 2. A single debug package libwx3.0-dbg containing symbols for all of the
RD> > above.
RD>
RD> Do the -dbg packages need to have dependencies on the lib packages?
RD> IOW, will installing libwx3.0-dbg force the installation of all the
RD> libwx* packages?
It's true that usually foo-dbg depends on foo but in this case this would
seem to be undesirable... Does anybody (Devid?) know if there is any Debian
rule/convention concerning this?
If we choose (a) or (b) from above we could have libwxbase3.0-dbg and
libwxgtk3.0-dbg but I really wouldn't want to have many -dbg packages. So
if -dbg package must depend on the library itself in virtue of some Debian
policy, then this would be a strong argument against (c).
RD> > 3. Development packages:
RD> > - libwx3.0-headers containing all headers (excluding setup.h)
RD> > - libwx3.0-dev containing wx-config, wxrc and setup.h
RD>
RD> Is there any need/desire to have an additional dev package containing
RD> the static libraries?
I don't think so, what would they be for?
Thanks,
VZ
Vadim Zeitlin
DAF> Hi to all
DAF> > It's true that usually foo-dbg depends on foo but in this case this would
DAF> > seem to be undesirable... Does anybody (Devid?) know if there is any Debian
DAF> > rule/convention concerning this?
DAF> If foo-dbg doesn't depend on foo, lintian will show a lintian warning
DAF> like this:
Thanks for the information!
DAF> I prefer to have a lintian clean package (lintian checks a package to
DAF> control if it respect Debian Policy or not), so I think that foo-dbg
DAF> must depend on foo package.
Yes, I definitely agree that new packages should be clean.
Well, so apparently the choice is between
(a') Single libwx package and single libwx-dbg package
(b') Two libwxbase and libwxgtk packages and two libwx{base,gtk}-dbg ones
(b'') Two libwxbase and libwxgtk packages but single libwx-dbg one
(c') Many libwxfoo packages and many libwxfoo-dbg ones
AFAICS both Robin and you prefer (b') or (b'') and among those 2 I think
(b') is preferable. (c') seems less attractive now but I'd still would
support having multiple packages personally. However I think that you know
Debian[*] conventions better than me/us and besides you're going to do the
work so it should be your decision.
Thanks!
VZ
[*] Political correctness notice: whenever I write "Debian" it should be
read as "Debian or Ubuntu or other Debian-derived distributions"
Devid Antonio Filoni
> It's true that usually foo-dbg depends on foo but in this case this would
> seem to be undesirable... Does anybody (Devid?) know if there is any Debian
> rule/convention concerning this?
W dbg-package-missing-depends
This package has a name of the form of "X-dbg", indicating it contains
detached debugging symbols for the package X. If so, it should depend
on the corresponding package, generally with (= ${binary:Version})
since the debugging symbols are only useful with the binaries created
by the same build.
I prefer to have a lintian clean package (lintian checks a package to
control if it respect Debian Policy or not), so I think that foo-dbg
Vaclav Slavik
> Having less packages IMHO clearly simplifies users' life here.
User's life is same either way: "apt-get install yourapp". No need to
install wx packages manually, that's what dependencies are for.
Vaclav
Robin Dunn
> On Sat, 14 Jun 2008 00:06:26 +0200 Devid Antonio Filoni <devi...@gmail.com> wrote:
>
> DAF> Hi to all
> DAF> > It's true that usually foo-dbg depends on foo but in this case this would
> DAF> > seem to be undesirable... Does anybody (Devid?) know if there is any Debian
> DAF> > rule/convention concerning this?
> DAF> If foo-dbg doesn't depend on foo, lintian will show a lintian warning
> DAF> like this:
>
> Thanks for the information!
>
> DAF> I prefer to have a lintian clean package (lintian checks a package to
> DAF> control if it respect Debian Policy or not), so I think that foo-dbg
> DAF> must depend on foo package.
>
> Yes, I definitely agree that new packages should be clean.
>
>
> Well, so apparently the choice is between
>
> (a') Single libwx package and single libwx-dbg package
> (b') Two libwxbase and libwxgtk packages and two libwx{base,gtk}-dbg ones
> (b'') Two libwxbase and libwxgtk packages but single libwx-dbg one
> (c') Many libwxfoo packages and many libwxfoo-dbg ones
>
> AFAICS both Robin and you prefer (b') or (b'') and among those 2 I think
> (b') is preferable. (c') seems less attractive now but I'd still would
> support having multiple packages personally. However I think that you know
> Debian[*] conventions better than me/us and besides you're going to do the
> work so it should be your decision.
This might work:
(c'') Have many libwxfoo packages, and a libwx that is a virtual package
that depends on all the libwxfoo packages, and a single libwx-dbg that
depends on the virtual libwx package.
Robin Dunn
> On Fri, 13 Jun 2008 11:41:41 -0700 Robin Dunn <ro...@alldunn.com> wrote:
>
> RD> There are some advantages to keeping them together
>
> I do realize this but I think they're compensated by disadvantages of
> having to understand both C++ and Python part whenever you modify the files
> even if you're interested in only one of them. I.e. I believe the savings
> in complexity will be significant enough to compensate for these
> advantages.
Very possible.
> RD> > 3. Development packages:
> RD> > - libwx3.0-headers containing all headers (excluding setup.h)
> RD> > - libwx3.0-dev containing wx-config, wxrc and setup.h
> RD>
> RD> Is there any need/desire to have an additional dev package containing
> RD> the static libraries?
>
> I don't think so, what would they be for?
For people that want to link statically but use standard packages. On
further thought though I suppose that this would be needed only rarely
and not worth the time or bandwidth to produce the package.
Stefa...@t-online.de
> > Having less packages IMHO clearly simplifies users' life here.
>
> User's life is same either way: "apt-get install yourapp". No need to
> install wx packages manually, that's what dependencies are for.
Yes, I realize this and it's working nicely in theory and most of the
time
(probably more than 99%) in practice, it's just the remaining
pathological
cases, I'm worrying about (and that I'm encountering every now and
then),
e.g. (just a made up example because I don't remember the last "real"
one)
a debian box without internet connectivity. I transfer the desired
package
on a CD, am told that packages are missing, collect required packages
the
next day, come back only to be told that those new packages in turn
require
other packages and so on ...
To summarize, I think that having lots of packages could be a problem in
unusual situations, while I don't see the compensating advantage on the
other
side.
Regards,
Stefan
Vadim Zeitlin
RD> > Well, so apparently the choice is between
RD> >
RD> > (a') Single libwx package and single libwx-dbg package
RD> > (b') Two libwxbase and libwxgtk packages and two libwx{base,gtk}-dbg ones
RD> > (b'') Two libwxbase and libwxgtk packages but single libwx-dbg one
RD> > (c') Many libwxfoo packages and many libwxfoo-dbg ones
RD> >
RD> > AFAICS both Robin and you prefer (b') or (b'') and among those 2 I think
RD> > (b') is preferable. (c') seems less attractive now but I'd still would
RD> > support having multiple packages personally. However I think that you know
RD> > Debian[*] conventions better than me/us and besides you're going to do the
RD> > work so it should be your decision.
RD>
RD> This might work:
RD>
RD> (c'') Have many libwxfoo packages, and a libwx that is a virtual package
RD> that depends on all the libwxfoo packages, and a single libwx-dbg that
RD> depends on the virtual libwx package.
Sorry, I should have written that I did think about libwx virtual package
and I think we should have it anyhow (for migration of the old packages at
least) but the problem is that if you need to install all the separate
libwxfoo packages anyhow if you need to debug any of them, then it somewhat
negates the point of splitting libwx in many packages in the first place.
But, again, personally I'm still favourable to (c) (whether with one or
two primes), it's just that I'm ready to be overruled by others.
Regards,
VZ
Vaclav Slavik
> To summarize, I think that having lots of packages could be a problem in
> unusual situations, while I don't see the compensating advantage on the
> other
> side.
I would think the advantage is obvious: it frequently actually means
_fewer_ dependencies, both in direct download size (you don't need wxAUI
or wxMedia to run Poedit) and in transitive dependencies (wxMedia pulls
in GStreamer and probably at least some of its plugins without which it
wouldn't work, which in turn pulls in A/V decoding libraries; wxAdv
pulls in libsdl, which in turn requires whatnot).
Vaclav
Stefa...@t-online.de
> I would think the advantage is obvious: it frequently actually means
> _fewer_ dependencies, both in direct download size (you don't need wxAUI
> or wxMedia to run Poedit) and in transitive dependencies (wxMedia pulls
> in GStreamer and probably at least some of its plugins without which it
> wouldn't work, which in turn pulls in A/V decoding libraries; wxAdv
> pulls in libsdl, which in turn requires whatnot).
Okay, I see it for wxMedia and maybe 2 or 3 others, but not for e.g. wxbase*net*
which is quite small and doesn't adds to the dependendies. Also, maybe we should
split wxAdv into several libraries, so you can easily get the stuff which doesn't
add new dependencies (e.g. wxGrid) while avoiding the parts that add dependencies
you don't like?
Regards,
Stefan
Devid Antonio Filoni
However, I will need help making the install files (what files goes
into a package, what in another, etc...), I will ask here for this
after the first buildtest. The work on the new package shouldn't take
a lot of time.
2008/8/2 Vadim Zeitlin <va...@wxwidgets.org>:
> On Sat, 2 Aug 2008 23:10:52 +0200 Devid Antonio Filoni <devi...@gmail.com> wrote:
>
> DAF> What svn I shoud use to make the package?
>
> The trunk -- this is what will become 2.9.0 (and 3.0 at some later time).
>
> Thanks,
> VZ
>
> _______________________________________________
> wx-dev mailing list
> wx-...@lists.wxwidgets.org
> http://lists.wxwidgets.org/mailman/listinfo/wx-dev
>
Devid Antonio Filoni
I need also to call the others?
2008/8/3 Vadim Zeitlin <va...@wxwidgets.org>:
> On Sun, 3 Aug 2008 00:58:19 +0200 Devid Antonio Filoni <devi...@gmail.com> wrote:
>
> DAF> http://svn.wxwidgets.org/svn/wx/wxWidgets/trunk/ right?
>
> Yes, exactly.
>
> DAF> However, I will need help making the install files (what files goes
> DAF> into a package, what in another, etc...),
>
> You can look at the current packages, build/bakefiles/make_dist.mk and
> distrib/scripts/manifets/*.rsp files for some answers...
>
> DAF> I will ask here for this after the first buildtest. The work on the
> DAF> new package shouldn't take a lot of time.
>
> Great!
Devid Antonio Filoni
about wxGTK and wxPython? I should continue to build only wxPython as
done? I also need a list of CFLAGS that I should use during build and
a list of choiced packages.
Thanks
Devid Filoni
Vadim Zeitlin
DAF> 2008/7/29 Vadim Zeitlin <va...@wxwidgets.org>:
DAF> > On Mon, 28 Jul 2008 16:31:03 +0200 Devid Antonio Filoni <devi...@gmail.com> wrote:
DAF> >
DAF> > DAF> I'm starting to work at the packages, but I need some infos, what
DAF> > DAF> about wxGTK and wxPython?
DAF> >
DAF> > I think we agreed on keeping them separate, i.e. make packages just for wx
DAF> > and then make separate wxPython packages which would depend on them.
DAF> Should I do the package of wxPython or wxGTK source?
I'm afraid I don't really understand the question. wxGTK package should
use wxGTK sources, of course.
Am I missing something?
VZ
Vadim Zeitlin
DAF> I'm starting to work at the packages, but I need some infos, what
DAF> about wxGTK and wxPython?
Hello,
I think we agreed on keeping them separate, i.e. make packages just for wx
and then make separate wxPython packages which would depend on them.
BTW, concerning "GTK" part of "wxGTK": it would be nice if this were a
variable which could be somehow set/changed to also allow producing
wxX11/wxDFB/... packages from the same files. But well, this is just a
"nice to have" thing, not a really indispensable one.
DAF> I also need a list of CFLAGS that I should use during build
There is nothing special to use in C{,PP,XX}FLAGS AFAIK. Did you have
something precise in mind?
DAF> and a list of choiced packages.
AFAIR we decided that it was up to you, as the person who is going to work
on it, to choose between the variants we considered. Maybe you could also
discuss it with other Ubuntu folks interested in wx to see what would
people prefer?
Thanks,
VZ
Vadim Zeitlin
DAF> There are four configure file
Sorry, where do you see the 3 other ones? If you mean the 3rd party
library ones then you shouldn't be concerned as a Debian package will
presumably always use the system versions of these libraries. Is there
anything else?
Thanks,
VZ