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

[Mark Brand]

>> 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",
>>     
>
> Installing them into lib/ would be more "unix-like". Note, however,
> that the DLLs will not be found there. But if they are in the same
> directory as the EXE file, Windows will find them.
>
> As MinGW and similar projects put their EXE files into bin/, it's
> sensible to put the DLL files there, too. This avoids much trouble.
>
>   

Agreed.

>> or maybe some new directory?
>>     
>
> This might make sense. However, that directory would have to be
> used by EXE files as well as DLL files. As far as I know, there
> is no existing standard or consensus about such a directory.
>
> That's why I think that "usr/i686-pc-mingw32/bin/" is not perfect,
> but is the candidate which fits best.
>
>   

I agree with you that usr/i686-pc-mingw32/bin is the best choice of the
existing directories and has good precedent. Its mixing executables for
different platforms is slightly uncomfortable.  But, as you point out
below, this directory is not normally in PATH anyway.  (PATH contains
usr/bin which has prefixed links to needed *build* platform executables
in usr/i686-pc-mingw32/bin.)

>> 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.
>>     
>
> Okay, that's an interesting point. So if there are EXE files
> which are needed by the library at runtime?

No, I didn't mean that. I am thinking of *applications* that invoke
command line tools. Think of a simple application (script, batch file,
or exe) that must run a query and process its results. It could spawn
tsql.exe to do this. Tsql.exe can regarded as a component of the
application and it's convenient to be able to distribute it.

>  This sounds very
> strange to me, but if there's really such a thing, it should
> be built by mingw-cross-env and installed to "usr/i686-pc-mingw32/bin/".
>   

Yes, I agree about usr/i686-pc-mingw32/bin.

> Currently, I don't allow any command line tools to be built
> in package FreeTDS. Please correct me if that as a misjudgement
> and tell me which EXE files are needed and thus should be generated
> in mingw-cross-env by default.
>   

I have been making a general argument for relaxing the general
prohibition against building or keeping  EXE files.  A related issue was
clarifying which directory such EXE files and DLLs should be installed
to, but I think that is settled now.

>> Again, this is about convenience for the user.  It doesn't mean
>> that these same binary DLLs should necessarily be distributed to end users.
>>     
>
> If it's just about users who tweak mingw-cross-env, I don't see
> any need to standardize their directory structures, as there is
> no exchange to be expected.
>   

The "convenience" I am thinking of is having the components needed for
running and/or distributing the application built with mingw-cross-env.

>
> If there's really a need for a policy, I'd vote for:
>
>     usr/i686-pc-mingw32/bin
>     
> for the reasons mentioned above.
>
>   

I agree.

Should mention that the "plugin" DLLs for Qt and nsis have their own
well-established directories, which makes them exceptions.  These are
the exceptions I know about.

-Mark