ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Chaney <a...@writingshow.com>
Subject Re: Ivy in C/C++ environment
Date Fri, 07 Dec 2012 17:29:51 GMT
I love Ivy and use it a lot, but I agree with Archie, probably CMake + 
rpm/deb is going to be much more effective for C/C++ than trying to 
build an Ant/Ivy solution.

Alan

On 12/7/2012 7:51 AM, Archie Cobbs wrote:
> The C/C++ world does have a de-facto standard for dependency management and
> builds. It's called RPM (or .deb, etc.).
>
> For example, check out the openSUSE build service<https://build.opensuse.org/>.
> You have a pile of C/C++ code and need to define dependency meta-data? OK,
> then create an RPM spec file. The spec file is the analog to your ivy file:
> it specifies what dependencies you have when building the code. Once built,
> the resulting RPM includes the runtime dependency information. Then deploy
> the RPM via zypper which automatically pulls in any other required packages
> to satisfy the runtime dependencies. So it's a different "language" but the
> overall process and goal is the same as with ivy.
>
> You can use the openSUSE build service online, or download and deploy your
> own private version. Or just build your RPMs some other, homebrew way. In
> any case, you end up producing an RPM repository containing built versions
> of your software, then deploy that software using zypper, etc. Everything
> is automated and reproducible.
>
> I have utilized this idea successfully in three separate startups. It works
> great.
>
> -Archie
>
> On Fri, Dec 7, 2012 at 9:09 AM, Qazwart <qazwart@gmail.com> wrote:
>
>> One of the nice things about Ivy is that it works with your current build
>> mechanism. You don't have to redo everything from scratch. I see the power
>> of Maven. However, converting 100 Ant projects into Maven instead of using
>> Ivy is asking for trouble.
>>
>> The main issue is that there doesn't seem to be a C share object
>> repository that Java has. Changing to Maven or Gradle wouldn't solve that
>> problem, yet it also means completely rewriting your whole build mechanism.
>>
>> There is either a C/C++ tool that provides access to a worldwide C share
>> object repository, or there isn't. I don't know how Java as a language
>> compares to C/C++. I know many C-Heads who turn up their noses at the very
>> mention of Java (It's not a real language unless you can accidentally
>> overwrite a buffer!).
>>
>> However Java is way ahead on build tools, and programming environment.
>> Continuous Integration is practically non-existent in C-World. How can it
>> be when it can take hours and dozens of systems to build an application?
>>   The C++ IDE world has no equivalent to Eclipse (unless you count Eclipse).
>> And, the concept of dependency management doesn't seem to exist.
>>
>> The best I can imagine is using a combination of Ant and Ivy to download
>> via <ivy:retrieve> the shared objects from a munged Nexus/Artifactory
>> server, and tying the whole build process together with Makefiles. I've
>> seen it work although it seems a bit Rube Goldbergish. (This causes the
>> bird to peck, turning on the fan, causing the sailboat to float away, and
>> starting the download of the required C Library from the Nexus Repo…).
>> After all, the main thing about Maven and Ivy is transitive dependencies.
>> Is there a Makefile to pom.xml/ivy.xml mechanism?
>>
>> It's been a while since I've worked in the C/C++ world. Maybe there is
>> some native tool that can do what Ivy and Maven does. If there is, use
>> that. There's a certain power with standards, even if you don't fully agree
>> with them.
>>
>> --
>> David Weintraub
>> David@Weintraub.name
>>
>> On Dec 7, 2012, at 1:59 AM, Marcel Overdijk <marceloverdijk@gmail.com>
>> wrote:
>>
>>> As we are also looking for alternatives that are a better fit, we are
>> also
>>> considering Gradle.
>>> Gradle also has an experimental C++ plugin:
>>> http://gradle.org/docs/current/userguide/cpp.html
>>> Something like this in theory it would mean you can use Gradle for both
>>> dependency resolving and building.
>>>
>>> I also found a couple of Maven plugins for C/C++ which might also be
>>> interesting:
>>> http://mojo.codehaus.org/maven-native/native-maven-plugin/usage.html
>>> http://java.freehep.org/freehep-nar-plugin/narDependencies.html
>
>


Mime
View raw message