Can gradle build C libraries and RPM distributions?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Can gradle build C libraries and RPM distributions?

Malcolm Gorman
Gradle looks very promising!

I have been asked to provide a new build and package system for our
next generation of servers running on Red Hat Linux. That means compiling
C code, Fortran code, Java code, and packaging each sub-project into
an RPM ready for distribution.

Is this a practical thing to do using Gradle at its current level of development?

I expect that I will need to call out to Ant to compile C and Fortran, and to invoke
an RPM package builder. Does that sound accurate to you?

What are your thoughts on this?

Mal.
Reply | Threaded
Open this post in threaded view
|

Re: Can gradle build C libraries and RPM distributions?

Russel Winder-2
On Mon, 2008-05-05 at 19:19 -0700, Malcolm Gorman wrote:
> Gradle looks very promising!
>
> I have been asked to provide a new build and package system for our
> next generation of servers running on Red Hat Linux. That means compiling
> C code, Fortran code, Java code, and packaging each sub-project into
> an RPM ready for distribution.
>
> Is this a practical thing to do using Gradle at its current level of
> development?

I am not sure the Ant tasks are really up to the job of handling C and
Fortran builds well.  I know there is a C/C++/Fortran task (cpptask in
ant-contrib) but it isn't very sophisticated -- but maybe I have missed
something.  Personally, I would use SCons for a C, C++, Fortran related
builds.

OK, this may seem disloyal given my involvement in Gant, Groovy and
Gradle, but it has to be accepted that different build systems have
grown up focused on different language support.  Rake is Ruby focused,
Ant, Maven, Gant and Gradle are Java/Groovy focused, and SCons is C/C
++/Fortran/LaTeX focused.

There is an Ant task for building Deb files -- cf.
http://code.google.com/p/ant-deb-task/ I guess someone must have an RPM
task.

SCons deosn't I think have explicit builders for Deb and RPM but it has
very good support for calling commands -- much nicer that Ant, etc.

> I expect that I will need to call out to Ant to compile C and Fortran, and
> to invoke
> an RPM package builder. Does that sound accurate to you?
>
> What are your thoughts on this?

As noted above I would accept the shift from Groovy to Python and use
SCons.
--
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Can gradle build C libraries and RPM distributions?

Ittay Dror

Russel Winder-4 wrote
I am not sure the Ant tasks are really up to the job of handling C and
Fortran builds well.  I know there is a C/C++/Fortran task (cpptask in
ant-contrib) but it isn't very sophisticated -- but maybe I have missed
something.  Personally, I would use SCons for a C, C++, Fortran related
builds.
cpptask is indeed not sophisticated and also not developed any more. Maven has the NAR plugin, it uses cpptask for the compilation but adds module dependencies and configuration. Maybe it can be ported to gradle?

Russel Winder-4 wrote
OK, this may seem disloyal given my involvement in Gant, Groovy and
Gradle, but it has to be accepted that different build systems have
grown up focused on different language support.  Rake is Ruby focused,
Ant, Maven, Gant and Gradle are Java/Groovy focused, and SCons is C/C
++/Fortran/LaTeX focused.
But if someone is working on a large project, involving both java and C, it is better if there is one build system. Not only does it mean you don't need to learn two frameworks, but it also gives you a single point of execution for building the whole product and handle dependencies (e.g., C code can implement JNI).

Reply | Threaded
Open this post in threaded view
|

Re: Can gradle build C libraries and RPM distributions?

Russel Winder-2
Ittay,

On Mon, 2008-05-26 at 23:35 -0700, Ittay Dror wrote:

> Russel Winder-4 wrote:
> >
> > I am not sure the Ant tasks are really up to the job of handling C and
> > Fortran builds well.  I know there is a C/C++/Fortran task (cpptask in
> > ant-contrib) but it isn't very sophisticated -- but maybe I have missed
> > something.  Personally, I would use SCons for a C, C++, Fortran related
> > builds.
> >
>
> cpptask is indeed not sophisticated and also not developed any more. Maven
> has the NAR plugin, it uses cpptask for the compilation but adds module
> dependencies and configuration. Maybe it can be ported to gradle?
I think the fact that it is not being developed further is probably very
telling of the amount of use C and C++ build gets in Ant.  Personally I
would prefer to write a Ant task wrapper for SCons and use SCons'
massive infrastructure for C and C++ builds rather than further develop
a new or maintain an old Ant task

> Russel Winder-4 wrote:
> >
> > OK, this may seem disloyal given my involvement in Gant, Groovy and
> > Gradle, but it has to be accepted that different build systems have
> > grown up focused on different language support.  Rake is Ruby focused,
> > Ant, Maven, Gant and Gradle are Java/Groovy focused, and SCons is C/C
> > ++/Fortran/LaTeX focused.
> >
> But if someone is working on a large project, involving both java and C, it
> is better if there is one build system. Not only does it mean you don't need
> to learn two frameworks, but it also gives you a single point of execution
> for building the whole product and handle dependencies (e.g., C code can
> implement JNI).
The question is which is the biggest party.  If the project is mostly
Java with a couple of C or C++ files then clearly the
Ant/Maven/Gant/Gradle route is the right one.  If the project is mostly
C/C++/Fortran with a little bit of Java then SCons would be the right
way to go.  SCons' Java support really isn't up to anything big, but it
is fine for little bits.

--
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Can gradle build C libraries and RPM distributions?

Ittay Dror
Russel,

Russel Winder-4 wrote
I think the fact that it is not being developed further is probably very
telling of the amount of use C and C++ build gets in Ant.  Personally I
would prefer to write a Ant task wrapper for SCons and use SCons'
massive infrastructure for C and C++ builds rather than further develop
a new or maintain an old Ant task
and then what if you want to build on windows? it means installing python, scons (i'm not sure how good it is in running on windows). and what about the difference in operating systems that require using a different set of compilers/linker for each (and different way of passing flags)? also, this wrapper may need to translate a lot of standard properties from the gradle file to the scons file (e.g., version numbers)

i think the reason that C/C++ is not used in ant is mainly because there's no good support for it. after modifying cpptask for a project i was doing, i can tell you it is written very badly (in my point of view of course), i think it is not maintained because it simply was not fun to develop anymore for the original author. i don't see a reason why c/c++ projects will not benefit from a tool like gradle (if you're using python+scons, why not use groovy+gradle?), especially because of the superior support for dependency management.
Reply | Threaded
Open this post in threaded view
|

Re: Can gradle build C libraries and RPM distributions?

Russel Winder-2
Ittay,

On Tue, 2008-05-27 at 06:22 -0700, Ittay Dror wrote:

> and then what if you want to build on windows? it means installing python,
> scons (i'm not sure how good it is in running on windows). and what about
> the difference in operating systems that require using a different set of
> compilers/linker for each (and different way of passing flags)? also, this
> wrapper may need to translate a lot of standard properties from the gradle
> file to the scons file (e.g., version numbers)

SCons works fine on Windows.  What SCons does is to detect which
compiler you have and to provide the appropriate options.  Thus the same
SConstruct file generally works on any platform.  If some platform
specifics are needed then a SConstruct file is actually just a Python
program so you have the whole power of SCons and Python available  to
describe the build.

This is of course the same rationale as why Gant and Gradle are going to
be the major build systems of the future for Java-based system, Groovy
is just a far better language of description than XML.

> i think the reason that C/C++ is not used in ant is mainly because there's
> no good support for it. after modifying cpptask for a project i was doing, i
> can tell you it is written very badly (in my point of view of course), i
> think it is not maintained because it simply was not fun to develop anymore
> for the original author. i don't see a reason why c/c++ projects will not
> benefit from a tool like gradle (if you're using python+scons, why not use
> groovy+gradle?), especially because of the superior support for dependency
> management.

It is a bit chicken and egg -- if the support is not good then no-one
will use it so things won't get better.  And as you say the cppTasks
code is not the best code I have seen.

In order for Gant or Gradle to be used for C, C++, Fortran, LaTeX builds
they have to have the infrastructure.  But SCons already has the
infrastructure so what motivation is there to replicate and rewrite it
in Groovy, when it is actually easier to use SCons?

BTW All the same arguments apply in the opposite direction for SCons'
Java support.

If there are people out there wishing to build a SCons equivalent C, C
++, Fortran infrastructure for Gant and Gradle then great, lets get on
with it.

--
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Can gradle build C libraries and RPM distributions?

Ittay Dror
Russel,
Russel Winder-4 wrote
SCons works fine on Windows.  What SCons does is to detect which
compiler you have and to provide the appropriate options.  Thus the same
SConstruct file generally works on any platform.  If some platform
specifics are needed then a SConstruct file is actually just a Python
program so you have the whole power of SCons and Python available  to
describe the build.
how does it know the appropriate options? what if i want to turn on warning level, optimization, etc.? each compiler (e.g. cl.exe, gcc) has its own logic

Russel Winder-4 wrote
In order for Gant or Gradle to be used for C, C++, Fortran, LaTeX builds
they have to have the infrastructure.  But SCons already has the
infrastructure so what motivation is there to replicate and rewrite it
in Groovy, when it is actually easier to use SCons?
Well, does scons provide dependency management like ivy? if my C code depends on xercesc, can I just define this dependency in the Sconstruct file and scons will download it and set the -I and -L,-l flags accordingly (and whatever other flags cl.exe uses)?

Ittay
Reply | Threaded
Open this post in threaded view
|

Re: Can gradle build C libraries and RPM distributions?

Russel Winder-2
Ittay,

On Tue, 2008-05-27 at 11:17 -0700, Ittay Dror wrote:

> how does it know the appropriate options? what if i want to turn on warning
> level, optimization, etc.? each compiler (e.g. cl.exe, gcc) has its own
> logic

Things like providing search directories, libraries, etc. are abstracted
and SCons knows how to format them for each of the compilers it knows
about -- this is analogous to what Ant does just using a different
syntax.  Specific options have to be given in the right format and so
you do have to switch on environment['PLATFORM'] -- this is much easier
than what you have to do in Ant.  So it is not all magic but the
decision making is fairly straightforward.  It could be argued that
SCons should do more.  There is a lively debate on the developer mailing
list as we email here!

> Well, does scons provide dependency management like ivy? if my C code
> depends on xercesc, can I just define this dependency in the Sconstruct file
> and scons will download it and set the -I and -L,-l flags accordingly (and
> whatever other flags cl.exe uses)?

Not as there is for Java, but then there is no common C, C++ library
dependency management infrastructure as there is for Java -- cf. Maven
and Ivy repositories.
 
There are tools for checking presence of libraries, files etc.
(basically à la Autoconf) but there is no automated download and
install.  This is not actually unreasonable as every platform requires
different builds of libraries, whereas there is an element of
commonality for jars which make them a littel more platform independent.

--
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Can gradle build C libraries and RPM distributions?

Ittay Dror
Russel,
Russel Winder-4 wrote
There are tools for checking presence of libraries, files etc.
(basically à la Autoconf) but there is no automated download and
install.  This is not actually unreasonable as every platform requires
different builds of libraries, whereas there is an element of
commonality for jars which make them a littel more platform independent.
This is what the maven nar plugin (java.freehep.org/freehep-nar-plugin/intro.html) does. It creates artifacts with a classifier that is based on the platform where the artifact was built (something like xercesc-2.5.0-i386-Linux.nar), this means that you can then use these artifacts when compiling your own modules (it uses the right artifact classifiers for the current platform) and also it is easy creating distributions containing multi-platform support because you can simply deploy all artifacts to an internal repository and then later gather them into an assembly tree.

Ittay