Defining toolchain

[GregDomjan]

Sorry for following ramble, wanted to get some thoughts down and start discussion.

It would be nice not to have to run multiple times to choose different versions of toolchain.

What is toolchain Vs what is dependency?

An MS VC compile has a default dependency on it's versions of C++ std lib, and if present on the Windows Platform SDK.
There are then 'cross compile' variations for arch where to find not just libs but also the tools to execute.
Some tool paths can be Language or SDK dependendant...
There are some default pairings of Compiler and platform SDK, and ability to change that choice.

I think I'd like to see NAR System dependencies able to support include/lib without having to package (not sure you could legally pacakge with MSVC headers/libs), Another problem being inconsistent cross architecture locations..

I've made local changes that are very specific to the Windows tool layout, can't just push it out for others.
Here is an aol config I have for Compiling against VC8/9/10/11 and WindowsSDK 7/7.1/8

#  VC8
Windows.msvc.8.toolspath=c:/Program Files/Microsoft Visual Studio 8

Windows.msvc.8.path=VC/VCPackages;Common7/IDE;Common7/Tools
Windows.msvc.8.include=VC/INCLUDE
Windows.msvc.8.include.ATLMFC=VC/ATLMFC/INCLUDE

#  V8 x86
x86.Windows.msvc.8.path=VC/bin
x86.Windows.msvc.8.lib=VC/LIB
x86.Windows.msvc.8.lib.ATLMFC=VC/ATLMFC/LIB

# V8 amd64
amd64.Windows.msvc.8.path=VC/bin/amd64
x86_amd64.Windows.msvc.8.path=VC/bin/x86_amd64
amd64.Windows.msvc.8.lib=VC/LIB/amd64
amd64.Windows.msvc.8.lib.ATLMFC=VC/ATLMFC/LIB/amd64

# V8 Intel
ia64.Windows.msvc.8.path=VC/bin/ia64
x86_ia64.Windows.msvc.8.path=VC/bin/x86_ia64
ia64.Windows.msvc.8.lib=VC/LIB/ia64
ia64.Windows.msvc.8.lib.ATLMFC=VC/ATLMFC/LIB/ia64

#  VC9
Windows.msvc.9.toolspath=c:/Program Files/Microsoft Visual Studio 9

Windows.msvc.9.path=VC/VCPackages;Common7/IDE;Common7/Tools
Windows.msvc.9.include=VC/INCLUDE
Windows.msvc.9.include.ATLMFC=VC/ATLMFC/INCLUDE

#  V9 x86
x86.Windows.msvc.9.path=VC/bin
x86.Windows.msvc.9.lib=VC/LIB
x86.Windows.msvc.9.lib.ATLMFC=VC/ATLMFC/LIB

# V9 amd64
amd64.Windows.msvc.9.path=VC/bin/amd64
x86_amd64.Windows.msvc.9.path=VC/bin/x86_amd64
amd64.Windows.msvc.9.lib=VC/LIB/amd64
amd64.Windows.msvc.9.lib.ATLMFC=VC/ATLMFC/LIB/amd64

# V9 Intel
ia64.Windows.msvc.9.path=VC/bin/ia64
x86_ia64.Windows.msvc.9.path=VC/bin/x86_ia64
ia64.Windows.msvc.9.lib=VC/LIB/ia64
ia64.Windows.msvc.9.lib.ATLMFC=VC/ATLMFC/LIB/ia64

#  V10
Windows.msvc.10.toolspath=c:/Program Files/Microsoft Visual Studio 10.0

Windows.msvc.10.path=VC/VCPackages;Common7/IDE;Common7/Tools
Windows.msvc.10.include=VC/INCLUDE
Windows.msvc.10.include.ATLMFC=VC/ATLMFC/INCLUDE

#  V10 x86
x86.Windows.msvc.10.path=VC/bin
x86.Windows.msvc.10.lib=VC/LIB
x86.Windows.msvc.10.lib.ATLMFC=VC/ATLMFC/LIB

# V10 amd64
amd64.Windows.msvc.10.path=VC/bin/amd64
x86_amd64.Windows.msvc.10.path=VC/bin/x86_amd64
amd64.Windows.msvc.10.lib=VC/LIB/amd64
amd64.Windows.msvc.10.lib.ATLMFC=VC/ATLMFC/LIB/amd64

# V10 Intel
ia64.Windows.msvc.10.path=VC/bin/ia64
x86_ia64.Windows.msvc.10.path=VC/bin/x86_ia64
ia64.Windows.msvc.10.lib=VC/LIB/ia64
ia64.Windows.msvc.10.lib.ATLMFC=VC/ATLMFC/LIB/ia64

#  V11
Windows.msvc.11.toolspath=c:/Program Files/Microsoft Visual Studio 11.0

Windows.msvc.11.path=VC/VCPackages;Common7/IDE;Common7/Tools
Windows.msvc.11.include=VC/INCLUDE
Windows.msvc.11.include.ATLMFC=VC/ATLMFC/INCLUDE

#  V11 x86
x86.Windows.msvc.11.path=VC/bin
x86.Windows.msvc.11.lib=VC/LIB
x86.Windows.msvc.11.lib.ATLMFC=VC/ATLMFC/LIB

# V11 amd64
amd64.Windows.msvc.11.path=VC/bin/amd64
x86_amd64.Windows.msvc.11.path=VC/bin/x86_amd64
amd64.Windows.msvc.11.lib=VC/LIB/amd64
amd64.Windows.msvc.11.lib.ATLMFC=VC/ATLMFC/LIB/amd64

# V11 Intel
ia64.Windows.msvc.11.path=VC/bin/ia64
x86_ia64.Windows.msvc.11.path=VC/bin/x86_ia64
ia64.Windows.msvc.11.lib=VC/LIB/ia64
ia64.Windows.msvc.11.lib.ATLMFC=VC/ATLMFC/LIB/ia64

# Windows SDK - likely to be customised on a per install - this should be wrapped up in a dependent artifact.
WindowsSdk.6a.toolspath=C:/Program Files/Microsoft SDKs/Windows/v6.0A
WindowsSdk.6.toolspath=C:/Program Files/Microsoft SDKs/Windows/v6.0
WindowsSdk.7a.toolspath=C:/Program Files/Microsoft SDKs/Windows/v7.0A
WindowsSdk.7.toolspath=C:/Program Files/Microsoft SDKs/Windows/v7.0
WindowsSdk.7.1.toolspath=C:/Program Files/Microsoft SDKs/Windows/v7.1
WindowsSdk.8.toolspath=C:/Program Files/Windows Kits/8.0

# Windows SDK 7a (comes with the Visual Studio Install)
WindowsSdk.7a.include=include

x86.WindowsSdk.7a.lib=lib
amd64.WindowsSdk.7a.lib=lib/x64
ia64.WindowsSdk.7a.lib=lib/ia64

x86.WindowsSdk.7a.path=bin
amd64.WindowsSdk.7a.path=bin/x64
ia64.WindowsSdk.7a.path=bin/x64

# Windows SDK 7 
WindowsSdk.7.include=include

x86.WindowsSdk.7.lib=lib
amd64.WindowsSdk.7.lib=lib/x64
ia64.WindowsSdk.7.lib=lib/ia64

# PATH=
x86.WindowsSdk.7.path=bin
amd64.WindowsSdk.7.path=bin/x64
ia64.WindowsSdk.7.path=bin/x64

#x86.WindowsSdk.7.path=bin;bin/NETFX 4.0 Tools
#amd64.WindowsSdk.7.path=bin/x64;bin/NETFX 4.0 Tools/x64
#ia64.WindowsSdk.7.path=bin/ia64;bin/NETFX 4.0 Tools/ia64

# Windows SDK 7.1 
WindowsSdk.7.1.include=include

x86.WindowsSdk.7.1.lib=lib
amd64.WindowsSdk.7.1.lib=lib/x64
ia64.WindowsSdk.7.1.lib=lib/ia64

# PATH=
x86.WindowsSdk.7.1.path=bin
amd64.WindowsSdk.7.1.path=bin/x64
ia64.WindowsSdk.7.1.path=bin/x64

# Windows SDK 8 
WindowsSdk.8.include=include/um;include/shared

x86.WindowsSdk.8.lib=Lib/win8/um/x86
amd64.WindowsSdk.8.lib=Lib/win8/um/x64
#ia64.WindowsSdk.8.lib=Lib/win8/um/ia64

# PATH=
x86.WindowsSdk.8.path=bin/x86
amd64.WindowsSdk.8.path=bin/x64
ia64.WindowsSdk.8.path=bin/x64

[toonetown]

I like where this is heading - and it sounds good to me, but I would suggest putting the "toolspath" variable as a configuration in the Pom so you can use, for example, the VS80COMNTOOLS environment variable to locate it (or to select between profiles)

Either that, or provide some sort of variable expansion in the aol.properties file.

[ctrueden]

Either that, or provide some sort of variable expansion in the aol.properties file.

See @toonetown's issue #51.

[dscho]

Hmm. I think this needs a little more thinking -- just like #51. Can we agree to postpone this after the 3.0.0 release? If not, feel free to remove the label (but I'd appreciate a dedicated focus to resolve this issue very, very soon in that case because we delayed 3.0.0 for long enough, I think...)

[GregDomjan]

Post 3.0.0 is fine by me

[dscho]

@GregDomjan I just see a lot of trouble coming our way by making everything very complicated. It would be nice, of course, to support different toolchains, especially on the same computer, but how do we make it easy to use?

[GregDomjan]

@dscho I take your point that nar-maven-plugin would be more complicated, or at least have more to maintain. I feel it will make usage less complicated (if done well).
There is already adding in other NAR specific configuration to handle the same. So rather from my thinking it is about moving what is already complicated to follow the maven provided method of toolchain to change how it is complicated.

When the environment where maven is run is not sufficient to specify all the settings - such as running some configuration tool (vcvars.bat) before running maven and only having a single version of the toolset available for the build.
At the moment some NAR specific values have to be set and configured manually to manage the toolset paths.

toolchain would allow a more generic maven approach to such config, and from that theory be more easily configured through having some existing knowledge.

Closely tied to this issue is SDKs that get installed as large groups or interconnected artifacts. Repackaging into maven would be time consuming, however using <system> to include is hiding a dependency unless it is truly a system library. I would consider the std c/C++ to be part of that issue and also the windows platform sdk.

[dscho]

I take your point that nar-maven-plugin would be more complicated, or at least have more to maintain. I feel it will make usage less complicated (if done well).

I have no doubt that it would make usage less complicated, but I have strong doubts that anyone will have enough time and motivation to do it well...

For example, I personally have zero experience with toolchains, and I definitely have not enough time to add more toolchain support than we already have...

[dscho]

@GregDomjan I assign this to you. Please feel free to address it, or in the alternative to close it.

[ctrueden]

Let's discuss on the maven-nar list.

[r2d2bol]

I would be interested in these features. Is there a way to revive this issue?