Re: [lmi] Native lmi build under Linux

[Vadim Zeitlin]

On Thu, 8 Oct 2020 23:53:43 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> On 2020-10-08 21:18, Vadim Zeitlin wrote:
[...]
GC> > I'm not sure if there is some way
GC> > of defining LMI_SO so that it could occur after the function return type,
GC> > but I don't think so: this works when it's defined as __declspec(dllfoo),
GC> > but the visibility attribute can't occur in the middle of a declaration,
GC> > AFAIK.
GC> 
GC> Zomg visibility--I've dreamt of that since at least 
2005-12-12T01:20:12+00:00
GC> according to `git log -G'fvisibility'`. The dll attributes were useful for
GC> supporting multiple msw-native compilers, when such things existed; but
GC> visibility has its own "fandom" page:
GC>   https://gcc.gnu.org/wiki/Visibility
GC> 
GC> >  Of course, maybe you're not actually testing build_type=so_test and in
GC> 
GC> Hadn't thought of it yet.

 FWIW I think it should be the default under Unix platforms. But for this
it'd need to be made to work first, of course.

GC> > this case your build should work without all these LMI_SO changes. However
GC> > you may still need some of the other ones, already done in this PR. E.g.
GC> > you can see that Ilya omits --host option when not cross-compiling, which
GC> > does indeed solve the issue with wxWidgets you've encountered, as I 
thought
GC> > it would.
GC> 
GC> Well, that would have saved me more than one minute.
GC> 
GC> I didn't confer with you first because, well, this morning I just
GC> woke up and decided this would be the day for a GTK build at last.

 The amazing thing is that I've been thinking about setting up CI builds
for lmi, including both MSW and GTK versions, for literally years and we've
finally got around to it only a few days ago: Ilya has finished the first
working version of his PR just yesterday.

GC> >  Then there is also the change to set_toolchain.sh which is, IMO, not
GC> > correct as it's written right now, but this file still needs to be changed
GC> > to avoid using Wine for native builds.
GC> 
GC> It worked for me. But that sounds like something I want to look into.
GC> 
GC> > And, related to this, I wonder what
GC> > do you think about the changes to test_coding_rules_test.sh which look 
good
GC> > to me, i.e. it seems to be better to reuse set_toolchain.sh in this script
GC> > rather than partially duplicate it, but perhaps you had some reason not to
GC> > do it that I'm not aware about?
GC> 
GC> There should ideally be no duplication: 'test_coding_rules_test.sh'
GC> should set everything, and everything else should depend on it
GC> (makefiles depend indirectly, via 'transume_toolchain.sh').
GC> 
GC> Or that was the dream. If you and Ilya have taken some more steps
GC> toward the end of that rainbow, I'm eager to follow.

 Sorry, I'm not sure, I'll have to check it again, but not today.

GC> >  Again, I don't want to distract you from the other tasks you're working
GC> 
GC> Today I decided to push all that other stuff aside and work on the
GC> highest-value task that never seemed to rise to the top of the
GC> priority queue. GTK was more attainable than I'd thought.

 Well, it does build out of the box using configure since quite a few
years, so it's not that surprising.

GC> >  Ideally I'd really like to:
GC> > 
GC> > 1. Apply the minimal fixes to make the simple (i.e. without LMI_SO) build
GC> >    work under Linux out of the box.
GC> > 2. Apply my upcoming PRs moving third party libraries to submodules (and
GC> >    updating them).
GC> > 3. Apply the big, but trivial, patch fixing LMI_SO locations and allowing
GC> >    build_type=so_test to work under Linux too.
GC> > 
GC> >  What do you think?
GC> 
GC> Sounds good, though I haven't looked at any of that work in detail yet.
GC> 
GC> Are you suggesting that I should pull in (1) now, even before
GC> you finish (2)? Won't we be creating conflicts that might be
GC> avoided by imposing a brief interregnum to clear the submodule
GC> stuff, as though you had a lock on a cvs repository? Or are
GC> there only certain files that you'd need to "lock", which are
GC> different from the ones modified by PR 158?

 There is some overlap between the two, e.g. PR 158 modifies
install_libxml2_libxslt.sh, while my PR 157 renames this file to
install_xml_libraries.sh (as it now installs 4 XML libraries, with xmlwrapp
and xsltwrapp), so _absolutely_ ideally I'd indeed do (2) first, but if
you're working on (1) right now, I could rebase my changes, resolving a few
conflicts I'm going to have, later.

 I.e. of course I'd rather not have any conflicts at all, but if we're
going to have them anyhow, I'd prefer to have them here and resolve them
myself, rather than asking you to do it.

 Regards,
VZ

pgpWZZR9dlMIQ.pgp
Description: PGP signature