Re: [lmi] Native lmi build under Linux

[Greg Chicares]

On 2020-10-08 21:18, Vadim Zeitlin wrote:
>  Hello,
> 
>  I've realized that if you're working on native lmi build right now you're
> probably going to duplicate the number of changes already done in
> 
>       https://github.com/vadz/lmi/pull/158

I think the only one I've duplicated is this:
  Don't link ws2_32 lib for native Linux build of XML libraries
so I haven't yet wasted more than about one minute.

>  This PR changes .github/workflows/ci.yml file that you're not interested
> in (although perhaps you might be... e.g. IMO LD_LIBRARY_PATH should be
> handled by lmi makefiles themselves instead of by doing it in this script)
> but it also changes a lot of other files.

I'll be glad to take a look. But I think I should wait until
your submodule changes are complete, right?

> I'm not sure if there is some way
> of defining LMI_SO so that it could occur after the function return type,
> but I don't think so: this works when it's defined as __declspec(dllfoo),
> but the visibility attribute can't occur in the middle of a declaration,
> AFAIK.

Zomg visibility--I've dreamt of that since at least 2005-12-12T01:20:12+00:00
according to `git log -G'fvisibility'`. The dll attributes were useful for
supporting multiple msw-native compilers, when such things existed; but
visibility has its own "fandom" page:
  https://gcc.gnu.org/wiki/Visibility

>  Of course, maybe you're not actually testing build_type=so_test and in

Hadn't thought of it yet.

> this case your build should work without all these LMI_SO changes. However
> you may still need some of the other ones, already done in this PR. E.g.
> you can see that Ilya omits --host option when not cross-compiling, which
> does indeed solve the issue with wxWidgets you've encountered, as I thought
> it would.

Well, that would have saved me more than one minute.

I didn't confer with you first because, well, this morning I just
woke up and decided this would be the day for a GTK build at last.

>  Then there is also the change to set_toolchain.sh which is, IMO, not
> correct as it's written right now, but this file still needs to be changed
> to avoid using Wine for native builds.

It worked for me. But that sounds like something I want to look into.

> And, related to this, I wonder what
> do you think about the changes to test_coding_rules_test.sh which look good
> to me, i.e. it seems to be better to reuse set_toolchain.sh in this script
> rather than partially duplicate it, but perhaps you had some reason not to
> do it that I'm not aware about?

There should ideally be no duplication: 'test_coding_rules_test.sh'
should set everything, and everything else should depend on it
(makefiles depend indirectly, via 'transume_toolchain.sh').

Or that was the dream. If you and Ilya have taken some more steps
toward the end of that rainbow, I'm eager to follow.

>  Again, I don't want to distract you from the other tasks you're working

Today I decided to push all that other stuff aside and work on the
highest-value task that never seemed to rise to the top of the
priority queue. GTK was more attainable than I'd thought.

> on, but I'm just afraid that you're going to run into all the same problems
> that Ilya has already fixed.

Not yet, but I'm really glad you've brought this up now.

> And even if you don't agree with his fixes
> (and as you can see from the comments I left there, even I don't agree with
> all of them), it should hopefully be still useful at least to see his
> solutions to these problems, even if you decide to do something different
> about them.
> 
>  Ideally I'd really like to:
> 
> 1. Apply the minimal fixes to make the simple (i.e. without LMI_SO) build
>    work under Linux out of the box.
> 2. Apply my upcoming PRs moving third party libraries to submodules (and
>    updating them).
> 3. Apply the big, but trivial, patch fixing LMI_SO locations and allowing
>    build_type=so_test to work under Linux too.
> 
>  What do you think?

Sounds good, though I haven't looked at any of that work in detail yet.

Are you suggesting that I should pull in (1) now, even before
you finish (2)? Won't we be creating conflicts that might be
avoided by imposing a brief interregnum to clear the submodule
stuff, as though you had a lock on a cvs repository? Or are
there only certain files that you'd need to "lock", which are
different from the ones modified by PR 158?