Hello,
I have started migrating a somewhat large (mostly) C++ project to
Gradle, coming from a set of Visual Studio solutions, various makefiles
and random oddities. Basically it has to build for Windows, Linux, OS X,
iOS, Android and Windows Phone, with some glue here and there on the
mobile targets.
Having spent some time with the latest Gradle builds, I have some
questions and suggestions. Keep in mind that those questions consider
Gradle is already capable of building for all those targets: just assume
I'll provide the pull requests to make it happen, I just need to know
how it should be done.
1. What is the simplest way to have a source set apply to only one
target platform?
For example, with this setup:
sources {
main {
cpp { }
objcpp { }
}
}
targetPlatforms {
windows { }
ios { }
}
How can I easily say "use the objcpp sourceset only for the ios target
platform"? Or possibly the other way around, "for the ios target
platform, use the cpp and objcpp sourcesets". I guess each has its own
advantages :).
2. Could the DSL for target platforms be improved?
Right now, platforms hold information about the architecture and
operating system. I believe it would make sense to extend this
information for each supported platform type in order to provide extra
information for that platform. Basically, you'd get something like this:
targetPlatforms {
windows(Win32) {
sdk '8.1' // include path for
Windows SDK 8.1
version '6.2' // #define _WIN32_WINNT
0x0602 (same as version target: '6.2')
unicode true // #define _UNICODE
icon name: 'MyApp' // fill the icon
information in a .rc
productName 'MyApp' // fill the product
information in a .rc (defaults to the project name)
productVersion '1.0.0.0' // fill the version
information in a .rc (defaults to the project version)
companyName 'My Company' // fill the company
information in a .rc (defaults to the project group)
}
ios(iOS) {
sdk '7.1' // -isysroot version or
path
version min: '6.0' target: '7.1' // minimum and target
versions
frameworks 'Foundation', 'UIKit' // link with
sdk/System/Library/Framework/Foundation.framework/Foundation, ...
icon name: 'MyApp' prerendered: true // fill the
CFBundleIcons information in a .plist
productName 'MyApp' // fill the product
information in a .plist (defaults to the project name)
productVersion '1.0.0.0' // fill the version
information in a .plist (defaults to the project version)
}
android(Android) {
sdk '19' // Android SDK version
or path
ndk 'r9b' // Android NDK version
or path
version min: '17' target: '19' // minimum and target
versions (<uses-sdk/>)
icon name: 'MyApp' // fill the
<application android:icon="xx"/> in the Android manifest
productName 'MyApp' // fill the
<application android:label="xx"/> in the Android manifest (defaults to
the project name)
productVersion '1.0.0.0' // fill the <manifest
android:versionName="xx"/> in the Android manifest (defaults to the
project version)
}
}
targetArchitectures {
x64 {
platforms targetPlatforms.windows, targetPlatforms.linux,
targetPlatforms.osx
}
armv8 {
platforms targetPlatforms.ios, targetPlatforms.android
}
}
Right now the Windows SDK directory information is part of
VisualCppToolchain, but some people could want to build their Windows
application with other compilers. Also, in the example above, some of
the properties are applicable to multiple platforms. And having the
architectures separated from the platforms means you don't have to
duplicate information just because you want both an x86 and an x64 Win32
build.
3. How to properly share the resource.h file for Windows builds?
I already mentioned it in https://github.com/gradle/gradle/pull/225 but
it makes more sense here:
- .rc files generally include resource.h (which defines most of your
resource constants)
- said resource.h is then used from your C or C++ code to reference the
resources
Right now, if I put resource.h in src/main/rc, it seems wrong to include
"../rc/resource.h" from src/main/cpp. Something like exportedHeaders
seems closer to the right solution but then it's just shared with
another sourceset, not really exported from that particular component.
How could this be made to work nicely?
4. Can we change/add some default values?
Namely:
1) use src/xx/include instead of src/xx/headers, which is far more
conventional and intuitive to C/C++ developers
2) add default include's to source sets: **/*.cpp for C++, **/*.c for C,
etc
Right now, by default, we're compiling every header found in src/xx/cpp
(again not very intuitive).
That's about it for now :)
Michael
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
