add EiskaltDC++ to section "Projects which use MXE"

[pavelvat]

No description provided.

[starius]

👍

I have updated MXE build instructions of EiskaltDC++.

Additional suggestions:

• add EiskaltDC++ to mxe/plugins/apps
• build EiskaltDC++ in Travis with MXE. See https://travis-ci.org/zer0main/battleship as an example.

[pavelvat]

Additional suggestions

Ok, I'll do it later.

[starius]

Thanks!

[pavelvat]

build EiskaltDC++ in Travis with MXE

Done.
eiskaltdcpp/eiskaltdcpp@f55f65a
https://travis-ci.org/eiskaltdcpp/eiskaltdcpp

[pavelvat]

@starius

add EiskaltDC++ to mxe/plugins/apps

From your PR #1050:

$(MAKE) -C '$(1)' -j '$(JOBS)'
cp '$(1)'/src/release/qbittorrent.exe '$(PREFIX)/$(TARGET)/bin/'

Where is install directory for apps? EiskaltDC++ is installing icons, scripts, sounds into "./EiskaltDC++/resources" directory, binaries into "./EiskaltDC++" directory, dictionaries into "./EiskaltDC++/aspell" directory.
Maybe create the install directories in "$(PREFIX)/$(TARGET)/apps"? For example:

"$(PREFIX)/$(TARGET)/apps/Clementine"
"$(PREFIX)/$(TARGET)/apps/EiskaltDC++"
"$(PREFIX)/$(TARGET)/apps/qBittorrent"
...

[starius]

"$(PREFIX)/$(TARGET)/apps/Clementine"
"$(PREFIX)/$(TARGET)/apps/EiskaltDC++"
"$(PREFIX)/$(TARGET)/apps/qBittorrent"

I like this idea.

Does EiskaltDC++ work with such directories?

[pavelvat]

Does EiskaltDC++ work with such directories?

What?
Currently, EiskaltDC++ is supporting only shared builds, but static builds supporting also possible in future. In any way you can use

$(PKG)_BUILD_STATIC =

in EiskaltDC++.mk file.

[starius]

I mean, does it work with the following layout:

EiskaltDC++/
├── EiskaltDC++.exe
├── foo-0.dll
├── aspell/
└── resources/

?

[pavelvat]

Of course. Why not?
Shared build of any Qt application required ./plugins directory with qwindows.dll:

apps/EiskaltDC++/plugins/platforms/qwindows.dll

and qt.conf file in apps/EiskaltDC++ directory:

[Paths]
Plugins = ./plugins

Install script of EiskaltDC++: https://gist.github.com/pavelvat/87153221bd2463023007

[pavelvat]

TARGET x86_64-w64-mingw32.shared currently produce wrong executables for EiskaltDC++ (It is working in wine, but don't work under native Windows). Quick workaround to fix this commented this two lines: https://github.com/eiskaltdcpp/eiskaltdcpp/blob/master/dcpp/Util.cpp#L174-L175

[pavelvat]

Also need -DPERL_REGEX=OFF because EiskaltDC++ required build pcre.mk with option --enable-cpp

[starius]

Can we add --enable-cpp to pcre.mk?
If no, we can modify pcre build rules only in apps plugin.

[pavelvat]

Can we add --enable-cpp to pcre.mk?

It is not good idea, because many applications not required libpcrecpp.dll which requires addititional dependency from libstdc++-6.dll.

If no, we can modify pcre build rules only in apps plugin.

Is that possible? qtbase.mk depends on pcre.mk.

[pavelvat]

Seems commit b4decd3 broke linking with libaspell-15.dll: file is missing libdl.dll.a

[starius]

because many applications not required libpcrecpp.dll which requires addititional dependency from libstdc++-6.dll

Why do they get additional dependency? PCRE already install multiple DLLs and multiple pc-files:

usr/i686-w64-mingw32.shared/bin/libpcre-1.dll
usr/i686-w64-mingw32.shared/bin/libpcre16-0.dll
usr/i686-w64-mingw32.shared/bin/libpcreposix-0.dll
usr/i686-w64-mingw32.shared/bin/pcre-config
usr/i686-w64-mingw32.shared/include/pcre.h
usr/i686-w64-mingw32.shared/include/pcreposix.h
usr/i686-w64-mingw32.shared/installed/pcre
usr/i686-w64-mingw32.shared/lib/libpcre.dll.a
usr/i686-w64-mingw32.shared/lib/libpcre.la
usr/i686-w64-mingw32.shared/lib/libpcre16.dll.a
usr/i686-w64-mingw32.shared/lib/libpcre16.la
usr/i686-w64-mingw32.shared/lib/libpcreposix.dll.a
usr/i686-w64-mingw32.shared/lib/libpcreposix.la
usr/i686-w64-mingw32.shared/lib/pkgconfig/libpcre.pc
usr/i686-w64-mingw32.shared/lib/pkgconfig/libpcre16.pc
usr/i686-w64-mingw32.shared/lib/pkgconfig/libpcreposix.pc

Nothing will change for an application using libpcre-1.dll if PCRE installs also C++ libpcrecpp.dll.

[starius]

If no, we can modify pcre build rules only in apps plugin.

Is that possible? qtbase.mk depends on pcre.mk.

Plugins can change features of existing packages, not only add new packages. See gcc52 plugin: it changes gcc version from 4.9 to 5.2.

[pavelvat]

Nothing will change for an application using libpcre-1.dll if PCRE installs also C++ libpcrecpp.dll.

If so you can add --enable-cpp to pcre.mk.

[starius]

C++ support was disabled in cf3c939
@vog, why have you disabled C++ support in pcre?

[vog]

I honestly don't remember. This was 2009. :-)

Whatever my reasons were at that time - they almost certainly don't apply anymore. Feel free to enable C++ support in pcre and check if that makes any trouble.

[starius]

I'm building all packages for 8aa92bb

[tonytheodore]

Currently, EiskaltDC++ is supporting only shared builds

This doesn't make it the best candidate for an apps plugin - I imagined a large part of the appeal of those would be the static build?

[pavelvat]

Build of EiskaltDC++ for TARGET=i686-w64-mingw32.static has final linked errors after building of 100% sources with plugins of databases: qsql_sqlite, qsql_tds, qsql_odbc, qsql_psql.
In any case, the build of EiskaltDC ++ will not have full autonomy unlike the build of qBittorrent, because it requires the resources and aspell directories for run.

[starius]

Can you embed resources and aspell into executable? Qt has qrc for this purpose.

EiskaltDC ++ will not have full autonomy

At least all dependencies in one directory. It is also easy to use.

By the way, does EiskaltDC++ have an installer? NSIS provides easy way to make an installer.

[pavelvat]

Can you embed resources and aspell into executable?

Maybe in future...

At least all dependencies in one directory. It is also easy to use.

It is not important and can not improve the usability. More over, the portable version of EiskaltDC++ create settings configs in a directory of launch, so for usability only static file eiskaltdcpp-qt.exe is not enought, also required a directory for settings files. So "directory with settings + static build of eiskaltdcpp-qt.exe" or "directory with settings + shared build of eiskaltdcpp-qt.exe + dll dependencies" is not important for usability.

does EiskaltDC++ have an installer?

Of course:
https://github.com/eiskaltdcpp/eiskaltdcpp/blob/work/windows/EiskaltDC%2B%2B.nsi
http://sourceforge.net/projects/eiskaltdcpp/
http://sourceforge.net/projects/eiskaltdcpp/files/MS%20Windows/
Full list of features (in russian): https://ru.wikipedia.org/wiki/EiskaltDC%2B%2B

[starius]

So "directory with settings + static build of eiskaltdcpp-qt.exe" or "directory with settings + shared build of eiskaltdcpp-qt.exe + dll dependencies" is not important for usability.

Agreed. Just few more ideas. Settings can be stored in registry. QBittorrent also remembers its configuration, so it must be storing settings either to file or to registry.

https://github.com/eiskaltdcpp/eiskaltdcpp/blob/work/windows/EiskaltDC%2B%2B.nsi

Can you add generation of the installer to mk file, please? MXE has nsis.

[pavelvat]

Settings can be stored in registry.

Only file associations and info about program.

QBittorrent also remembers its configuration, so it must be storing settings either to file or to registry.

Applications for Windows are saving settings configs to standard configs directory:
C:\Users$USER_NAME\AppData
For example:
C:\Users\user\AppData\Local\EiskaltDC++
C:\Users\user\AppData\Roaming\EiskaltDC++

Portable versions of software must save settings to directory with *.exe file, because application can be launched on other computers.

Can you add generation of the installer to mk file, please?

Of course.

[pavelvat]

@starius

MXE has nsis.

Command $(TARGET)-makensis don't available on x86_64-w64-mingw32.static and x86_64-w64-mingw32.shared, because nsis.mk have supports only i686-w64-mingw32.static and i686-w64-mingw32.shared targets.

[starius]

@pavelvat, I use i686-w64-mingw32.static-makensis on all targets. For x86_64-w64-mingw32.static target it packs 64bit binaries into 32bit installer.

[pavelvat]

What about this case: settings.mk

# This variable controls the targets that will build.
MXE_TARGETS := x86_64-w64-mingw32.static x86_64-w64-mingw32.shared

Why does nsis.mk install Linux ELF-binaries into $(PREFIX)/$(TARGET)/bin? Not only into $(PREFIX)/bin?

[starius]

@pavelvat, I opened a separate for this: #1163

[starius]

What about this case: settings.mk

# This variable controls the targets that will build.
MXE_TARGETS := x86_64-w64-mingw32.static x86_64-w64-mingw32.shared

Additionally you can build nsis for i686-w64-mingw32.static with the following command:

$ make nsis MXE_TARGETS=i686-w64-mingw32.static

NSIS is similar to a compiler, because it has target. Target of NSIS doesn't need to be equal to target of a compiler which produced executables being packed by NSIS. However 32bit installer looks as if it installs 32bit executables, so it can be misleading, so we'd better to fix NSIS for x86_64-w64-mingw32.