Re: [Mingw-cross-env-list] what belongs in mingw-cross-env/usr/i686-pc-mingw32/bin?

[Mark Brand]

I'd like to follow up on a few points.

>> I am wondering which files are supposed to end up in
>> mingw-cross-env/usr/i686-pc-mingw32/bin. I see 4 categories:
>>
>> 1. Executables that run on the build system and play a role in building
>> software for the target system.
>> 2. DLLs for the target architecture.  Needed for preparing packages for
>> target system and testing under Wine.
>>     
>
> This is a dangerous generalization. Currently, there is just
> one package doing this - the mingwrt-dll .
>
> So in any case, DLL files shouldn't be built with mingw-cross-env.
> Instead, the official binary/DLL packages should be used.
> And BTW, exactly that's the case with "mingwm10.dll", too.
>
>   

Just to be clear, I'm not advocating that mingw-cross-env should change
its policy regarding building shared libraries.  But there will be times
when users have good reasons to make exceptions, and in these cases it's
not clear where the DLLs should be "installed" on the build system.

Suppose that the most convenient way to get a particular binary DLL for
Windows is to build it in mingw-cross-env. There might not be a suitable
"official binary/DLL".  This is not implausible.

One such case is a Qt application using some feature that only works
with shared Qt, like WebKit.  The user will have to edit qt.mk for a
shared build. Now, suppose we have patched the source code for the
build.  The user will need the patched versions of these DLLs to distribute.

I might also have a need for DLLs with debug info from time to time.

With default build options, packages tend to "install" their DLLs to
"bin". I agree that this does not make sense.  Would it be better to put
them in "lib",  or maybe some new directory?

>> 3. Executables (.exe) for the target architecture. Some of these are
>> useful to have since they can be used as components in packages prepared
>> for the target platform.
>>     
>
> It is true that some library packages contain programs, which
> fall into one of the 4 categories:
>
>     * Example programs
>     * Test programs
>     * Command line utilities
>     * Code generators needed by the build
>
> Note that none of them are interesting for us as win32 binary:
>
>     * Example programs are only interesting in source form
>   

Agreed.

>     * Test programs rarely run with Wine
>
>         (I think that when we want to add testing support
>          to mingw-cross-env, the only solution that is working
>          and maintainable for all libraries would be hand-written
>          or automatically generated programs.)
>   

Agreed.

>     * Command line utilities are usually not needed. The
>       only exceptions are GCC, Binutils, Pkg-config, Gettext
>       and Qt, but these are built natively, not cross, and
>       that the. They usually also get a symlink to usr/bin:
>
>           usr/bin/i686-pc-mingw32-TOOL   ->   /usr/i686-pc-mingw32/bin/TOOL
>   

Here I'm not so sure.  For example, the FreeTDS package has some some
command  line tools that are useful to have on Windows and may even be
embedded in some applications. It's quite possible that the most
convenient way to get these in binary form for Windows is to build them
in mingw-cross-env.

>     * Code generators are worthless when cross-compiled. They
>       need to be compiled natively, and they aren't installed,
>       because they aren't needed any longer after the build.
>   

Agreed, except for code generators like Qt's moc that we keep in bin
because it's needed to build Qt applications.


> That is why almost all packages are told not to install their
> binaries, either via ./configure arguments or via Make variables.
>
>   
>> Can also be used for testing under Wine.
>>     
>
> This is a very problematic argument for two reasons.
>
> First, mingw-cross-env is meant to be indenpendent of Wine, because
> most programs don't run properly in Wine, and because a dependency
> on Wine would make it much harder to make mingw-cross-env run
> on any Unix platform.
>   

I agree that mingw-cross-env should not depend on Wine. I wasn't
suggesting to change this.  I am thinking of convenience for
mingw-cross-env users. After I build a program for MInGW with
mingw-cross-env, it's nice to be able to run it under Wine and I will
need the DLLs to do so.

By the way, this is not only about Wine. If I have have the DLL fiiles I
need to run the program I'm building, it's very easy to use symbolic
links to link them into the same directory where my executable is
produced.  I can then run the program in Wine or Windows itself using
samba.  Again, this is about convenience for the user.  It doesn't mean
that these same binary DLLs should necessarily be distributed to end users.

>> 4. Shell scripts. A shell script could be intended for use on the build
>> system, but could also be useful on the target system running on MSYS.
>>     
>
> Shell scripts also fall into one of the above categories, where
> only the third kind (command line utilities) would be interesting.
>
>   

That sounds right. I don't know any plausible cases of this yet, so I'm
less concerned about scripts than dll and exe binaries.

>> Is it acceptable to mix architectures in "bin"?
>>     
>
> I don't think it is acceptable to put any DLL or EXE files
> into bin/. I don't think it's a good idea to even build them.
> Either build them natively or don't build them.
>
> The only win32 binary in bin/ is "mingwm10.dll", but it is a
> nasty work-around and thus a bad candidate for generalization.
>
> Note, however, that there's a related question of where to
> put externally downloaded DLL files. I don't think they need
> to go into mingw-cross-env's usr/ directory. But if there
> appears to be a good reason for doing that, our "bin" directory
> (i.e. usr/i686-pc-mingw32/bin/) would be the candidate which
> fits best.
>
>   

I guess the question boils down to this: Where should target platform
exe and dll files be "installed" in mingw-cross-env?  I agree that this
should be rare, but there seem to be a enough realistic scenarios to
motivate a policy.  The answer to this question probably also applies to
mingwm10.dll.

regards,

Mark