Redist package to only copy needed libraries

[gegenschall]

Hey everyone,

please excuse my ignorance by asking just a question: I have created a NuGet package for a rather large project (in fact Qt5). The redist package contains a lot of (large) DLLs that may not all be necessary for the referencing project. Is there any way to tell CoApp/Visual Studio to only copy those DLLs that have actually been linked to the projects executable (via .lib files)?

Thanks!

[zarkara]

You could separate the package into a hierarchy chain of packages, but
there is currently no logic to investigate what dlls have been linked to
the project executable. In fact its is designed the opposite way since the
nuget package during install adds any static libraries from the nuget
package as new linked files for the project.

-Ken

On Tue, Apr 7, 2015 at 6:24 AM, Max Liebkies [email protected]
wrote:

Hey everyone,

please excuse my ignorance by asking just a question: I have created a
NuGet package for a rather large project (in fact Qt5). The redist package
contains a lot of (large) DLLs that may not all be necessary for the
referencing project. Is there any way to tell CoApp/Visual Studio to
only copy those DLLs that have actually been linked to the projects
executable (via .lib files)?

Thanks!

—
Reply to this email directly or view it on GitHub
#102.

[cherullo]

Hi Max,

I packaged Qt4 for a private project, and I created different packages for
each Qt module (QtOpenGL, QtCore, QtXML, etc.), taking care to respect each
module's dependencies.
This way I was able to keep the packages size down.

Hope it helps.
[]s Renato C.

2015-04-07 7:24 GMT-03:00 Max Liebkies [email protected]:

Hey everyone,

please excuse my ignorance by asking just a question: I have created a
NuGet package for a rather large project (in fact Qt5). The redist package
contains a lot of (large) DLLs that may not all be necessary for the
referencing project. Is there any way to tell CoApp/Visual Studio to
only copy those DLLs that have actually been linked to the projects
executable (via .lib files)?

Thanks!

—
Reply to this email directly or view it on GitHub
#102.

[zarkara]

Renato did you happen to put your autopkg files for the qt4 hierarchy in a
public github? they would be great reference for qt5 i am guessing.

ken
On Apr 7, 2015 1:28 PM, "cherullo" [email protected] wrote:

Hi Max,

I packaged Qt4 for a private project, and I created different packages for
each Qt module (QtOpenGL, QtCore, QtXML, etc.), taking care to respect each
module's dependencies.
This way I was able to keep the packages size down.

Hope it helps.
[]s Renato C.

2015-04-07 7:24 GMT-03:00 Max Liebkies [email protected]:

Hey everyone,

please excuse my ignorance by asking just a question: I have created a
NuGet package for a rather large project (in fact Qt5). The redist
package
contains a lot of (large) DLLs that may not all be necessary for the
referencing project. Is there any way to tell CoApp/Visual Studio to
only copy those DLLs that have actually been linked to the projects
executable (via .lib files)?

Thanks!

—
Reply to this email directly or view it on GitHub
#102.

—
Reply to this email directly or view it on GitHub
#102 (comment)
.

[cherullo]

No, I didn't upload it to a public repo, sorry.

That's because we are changing our CMake workflow to use Nuget for
dependency management (ie. instead of using find_package, use a new
find_nuget), so our packages are not meant for direct VS consumption.

Also, it's very early in development.

I based my work on FindQt.cmake that ships with CMake itself. It shows the
module's dependencies, which sources files are required for app
compilation, etc.

I'm using CoApp's Autopackage to create our packages. For example, let's
take a look at QtGui.autopkg:

files {
autorunCmake : {
#destination: ${build_root}\cmake;
.\autorun.cmake\qtgui**;
}

    include2:  {
        #destination: ${build_root}\include\QtGui;
        .\include\QtGui\**;
    }

    // 'src' tag is already taken
    src2 : {
        #destination: ${build_root}\src\gui;
        .\src\gui\**;
    }

    [v100, dynamic, x64, cdecl, Release] {
        lib += .\lib\QtGui4.lib;
        bin += .\lib\QtGui4.dll;
    };

    [v100, dynamic, x64, cdecl, Debug] {
        lib += .\lib\QtGuid4.lib;
        bin += .\lib\QtGuid4.dll;
    };
};

dependencies {
    packages : {
        qtcore/4.7.3
    };
};

The autorunCmake thing is a small CMake script that setups some project
characteristics, much like target and props. We created this, non-standard.

Since Qt requires a certain structure under the include and src folders, I
had to recreate the file destinations too.

This package only carries QtGui's libs, of course, and has a dependency on
package QtCore.

I'm not well versed in MSBuild, so I didn't create the target and props
sections. Also Qt has a LOT of packages that we are not using... so it
would be a lot of work to do it all.

[]s Renato C.

2015-04-07 18:11 GMT-03:00 zarkara [email protected]:

Renato did you happen to put your autopkg files for the qt4 hierarchy in a
public github? they would be great reference for qt5 i am guessing.

ken
On Apr 7, 2015 1:28 PM, "cherullo" [email protected] wrote:

Hi Max,

I packaged Qt4 for a private project, and I created different packages
for
each Qt module (QtOpenGL, QtCore, QtXML, etc.), taking care to respect
each
module's dependencies.
This way I was able to keep the packages size down.

Hope it helps.
[]s Renato C.

2015-04-07 7:24 GMT-03:00 Max Liebkies [email protected]:

Hey everyone,

please excuse my ignorance by asking just a question: I have created a
NuGet package for a rather large project (in fact Qt5). The redist
package
contains a lot of (large) DLLs that may not all be necessary for the
referencing project. Is there any way to tell CoApp/Visual Studio to
only copy those DLLs that have actually been linked to the projects
executable (via .lib files)?

Thanks!

—
Reply to this email directly or view it on GitHub
#102.

—
Reply to this email directly or view it on GitHub
<
#102 (comment)

.

—
Reply to this email directly or view it on GitHub
#102 (comment)
.

[zarkara]

We use nuget for c++ packages and use another custom nuget package which is
just a target file that executes on beforebuild to restore source files
into the consumer projects. For instance we broke shared idl files into
their own repo which compiles and produces a shared idl nuget containing
the compiled idl files. we found the developers can reference the source
files easily and then the build server can perform nuget restore on a clean
repo.

ken
On Apr 10, 2015 11:06 AM, "cherullo" [email protected] wrote:

No, I didn't upload it to a public repo, sorry.

That's because we are changing our CMake workflow to use Nuget for
dependency management (ie. instead of using find_package, use a new
find_nuget), so our packages are not meant for direct VS consumption.

Also, it's very early in development.

I based my work on FindQt.cmake that ships with CMake itself. It shows the
module's dependencies, which sources files are required for app
compilation, etc.

I'm using CoApp's Autopackage to create our packages. For example, let's
take a look at QtGui.autopkg:

files {
autorunCmake : {
#destination: ${build_root}\cmake;
.\autorun.cmake\qtgui**;
}

include2: {
#destination: ${build_root}\include\QtGui;
.\include\QtGui**;
}

// 'src' tag is already taken
src2 : {
#destination: ${build_root}\src\gui;
.\src\gui**;
}

[v100, dynamic, x64, cdecl, Release] {
lib += .\lib\QtGui4.lib;
bin += .\lib\QtGui4.dll;
};

[v100, dynamic, x64, cdecl, Debug] {
lib += .\lib\QtGuid4.lib;
bin += .\lib\QtGuid4.dll;
};
};

dependencies {
packages : {
qtcore/4.7.3
};
};

The autorunCmake thing is a small CMake script that setups some project
characteristics, much like target and props. We created this, non-standard.

Since Qt requires a certain structure under the include and src folders, I
had to recreate the file destinations too.

This package only carries QtGui's libs, of course, and has a dependency on
package QtCore.

I'm not well versed in MSBuild, so I didn't create the target and props
sections. Also Qt has a LOT of packages that we are not using... so it
would be a lot of work to do it all.

[]s Renato C.

2015-04-07 18:11 GMT-03:00 zarkara [email protected]:

Renato did you happen to put your autopkg files for the qt4 hierarchy in
a
public github? they would be great reference for qt5 i am guessing.

ken
On Apr 7, 2015 1:28 PM, "cherullo" [email protected] wrote:

Hi Max,

I packaged Qt4 for a private project, and I created different packages
for
each Qt module (QtOpenGL, QtCore, QtXML, etc.), taking care to respect
each
module's dependencies.
This way I was able to keep the packages size down.

Hope it helps.
[]s Renato C.

2015-04-07 7:24 GMT-03:00 Max Liebkies [email protected]:

Hey everyone,

please excuse my ignorance by asking just a question: I have created
a
NuGet package for a rather large project (in fact Qt5). The redist
package
contains a lot of (large) DLLs that may not all be necessary for the
referencing project. Is there any way to tell CoApp/Visual Studio to
only copy those DLLs that have actually been linked to the projects
executable (via .lib files)?

Thanks!

—
Reply to this email directly or view it on GitHub
#102.

—
Reply to this email directly or view it on GitHub
<

#102 (comment)

.

—
Reply to this email directly or view it on GitHub
<
#102 (comment)

.

—
Reply to this email directly or view it on GitHub
#102 (comment)
.

[gegenschall]

Okay, i created a (hackish) Python script that

• Downloads and extracts Qt5 by version and VC tools version
• Automatically finds components (i.e. dlls, libs, pdbs), infers their architecture and build type
• Uses dumpbin to read dependencies to other Qt libraries and adds those to the individual autopkg script
• Creates the packages using a templating engine.

It works for me (TM) and has a few gotchas:

• Only testing with Windows 8.1 64-bit, VS2013
• Does not generate header or tools package
• You need Python 3
• It's kinda slow
• It does not clean up temporary files in %AppData%\Temp\

See: https://github.com/gegenschall/getqt