[Anthill-pro] Will anthillpro Supports C++ Build in Linux OS

Wed Aug 15 13:08:43 CDT 2007

Hi Eric

This really helps me a lot... Thanks a lot

Thanks
Joe

On 8/14/07, Eric Minick <etm at urbancode.com> wrote:
>
>
>
> Joseph wrote:
> > Thanks Yanko for quick email, i am researching for a unique tool that
> > supports the below requirements. Please mention "Y" for yes and "N" for
> No
> >
> >  Builds requirement
> >
> >
> > 1 The system shall perform builds which include source extraction,
> compile,
> > link, and package for instillation.
> >
> Yes. This is pretty much bread and butter for the build part of the tool.
> > 2.   The system shall manage builds with make and or data files that are
> > revision controlled with the source code.
> >
> Yes.
> > 3. The system shall build boot code, kernel, operating file system and
> > content and application software for all software and firmware within an
> > instrument product. This includes any non source binaries that are used.
> >
> Yes. Could you clarify non-source binaries. There may be some nice
> features around this.
> > 4. The system shall build components that originate as unchanged open
> source
> > packages, from their distributed format. This includes but is not
> limited to
> > uncompressing and unpacking of directory structures of source, make and
> data
> > files. This automation is to enforce use of unchanged external packages
> or
> > the tracking of any changes made to external packages.
> >
> Yes ( I think ).
>
> Could you clarify? Are you looking for Anthill to take a source tarball,
> unzip it, and then run a file system based change-log (basically detect
> which files are of a different date) against the unrolled directory?
> That should work fine if the unchanged files don't have a new date
> stamp, but I somewhat doubt that's true.
>
> Generally, we encourage teams to load those 3rd party binaries into
> Anthill's CodeStation tool, and number them with the release number
> provided by the 3rd party. The change logs publicly published by the
> open source tool provider should be better than whatever we can
> automatically produce. So long as the the build and release tool allows
> you to identify which release of the open source project the binary is
> associated with (and Anthill does) the public information is probably
> superior.
>
> We also see teams grabbing the publicly available change log and dumping
> it into a text file which is loaded into CodeStation alongside the
> tarball. That provides insulation against the open source project
> disappearing and the lost of the change information.
>
> CodeStation really pushes binary reuse, so if you could just load up a
> pre-compiled binary of the 3rd party library, that would be even better.
>
> If you wanted to do something really interesting, you could probably
> model the open source library as full project with a self referential
> dependency and run a recursive diff that highlights the changes since
> first version that was loaded in. That would require some bootstrapping,
> and I'm not sure it's been done before, but it would be quite doable
> with some help from the support team.
>
> But overall, I'm inclined to agree with Curtis that the approach here
> may be less than ideal. Perhaps I don't understand the requirements
> though. What's the 'real' requirement here that led to #4? If it's just
> clear, consistent reuse of 3rd party libraries, Anthill has you covered.
> > 5.The system shall support the export and import of code sets for work
> by
> > outside contractors.
> >
> N/A. This really is going to be mostly under the control of your source
> control / change management tool. Anthill won't stop you from doing it,
> but I'm not sure how it's going to be aware of it either. If you think
> it should be, please clarify.
> > 6   The system shall support controlled r/w source access to the system
> by
> > outside contractors.
> >
> Yes. There is clear role based security. You can determine who can do
> what within the system. So a contractor might be able to see the status
> of builds on (only) the project she is working on, but not be able to
> configure that build. Whether the contractor can kick off authoritative
> builds is up to you as well.
> > 7. The system shall perform the appropriate labeling and data tracking
> for a
> > builds tracking back to every individual source and data file used in
> its
> > creation.
> >
> Yes. The system can definitely apply a label back to source control at
> build time if you want it to. It can also do so at build promotion time.
> Once accomplished, it will be easy within the source control tool to
> know who last touched any given file. Anthill is also explicitly aware
> of changes between builds and knows which user touched which file when.
> > 8. The system shall produce release builds with intermediate file and
> final
> > targets placed within the controlled system area and within a
> developer's
> > local area.
> >
> Generally, developer builds are outside the scope of what Anthill sets
> out to do (see #9). But it will definitely produce authoritative builds.
> After producing an authoritative build, it will generally store the
> resulting binaries internally and when prompted to deliver them to a
> deployment target (like the controlled system area) it will do so.
> Deployments of this type are part of the reason why Anthill isn't really
> just a build tool. We like the term 'application lifecycle automation'.
> > 9.  The system shall perform release builds triggered by a schedule,
> > developer request.
> >
> Yes. Authoritative builds can be triggered manually, by schedule (simple
> or cron like), event within the system, commit into source control, or
> the completed build of a dependency. Which options are active are up to
> you.
>
> Note that I use the term 'authoritative' rather than 'release'. The
> presumption is that you don't know which build will be released at build
> time, so more builds are done that are releaseable. Perhaps only when QA
> approves a build is it released and marked as such in Anthill.
> > 10.The system shall perform developer builds triggered by and developer
> > local on demand.
> >
> This is a very uncommon useage pattern but possible. It absolutely can
> be done by installing agents on developer machines and having a custom
> workflow that selects them. This model is uncommon though. Usually,
> developers will build locally running the same scripts that Anthill uses
> to build authoritatively.
>
> Outside resources (like open source libraries) can be provided on the
> fly to the developers at build time in a similar way that they are
> injected into the authoritative builds. That simplifies things so the
> developer just has to run make. They don't have to log into a website to
> do a build on their own machine.
>
> Doing thier own builds with the build scripts has been found to be
> healthier and keep the build scripts in better shape.
> > 11.The system shall builds for the current work at the head of a
> development
> > branch or tree.
> >
> >
> Yes.
> > 12.The system shall builds for defect repairs or small functional
> additions
> > to any released code set.
> >
> Yes, but less common. Usually defect repairs are done by branching a
> release and committing defect fixes into that branch. That's easy. For
> some source control  tools, we see teams use the label that Anthill sets
> down as a baseline and they'll have a running target baseline. They'll
> fetch the baseline version of the code, and then check out a change set
> overlayed on top of it for a defect patch.
>
> A more common approach would be to build the project as a large number
> of independently built sub-modules and use dependency rules to assemble
> those modules. In a break-fix scenerio, only the impacted module would
> get a new build, and it would be assembled with the already approved
> versions of the other modules. Explicit build statuses provide support
> for notions like "the approved version of a sub-module".
> > Please guide me and let me know if AntHillPro supports above or is there
> any
> > other tool that supports this requirements
> >
> >
> Thanks Joe. You may have noticed that I used terms like "generally" and
> "usually" a lot. There's a lot of flexibility in the tool, but there are
> also some best practices (I hate that term) and assumed useage patterns.
> The more you deviate from those patterns, the more help you'll likely
> need from the support team. The good news there is that the support team
> are nice guys.
>
> You might want to contact sales at urbancode.com for a demo of the product
> and a more detailed discussion. They're also nice guys and aren't going
> to try a hard sell on you.
> > Thanks
> > Joe
> >
> > On 8/13/07, Curtis Yanko < curt_yanko at uhc.com> wrote:
> >
> >> Of course.
> >>
> >> - Curtis Yanko
> >> UnitedHealth Group IT
> >> Source->Build->Deploy
> >> Mail Route: CT028-06SA
> >> Internet email: curt_yanko at uhc.com
> >> Office 860.702.9059
> >> Cell 860.729.8171
> >>
> >>
> >>
> >>   *Joseph < yjvijay at gmail.com>*
> >> Sent by: anthill-pro-bounces at caladin.urbancode.com
> >>
> >> 08/13/2007 10:47 AM   Please respond to
> >> "AnthillPro user and support list." < anthill-pro at caladin.urbancode.com
> >
> >>
> >>    To
> >> anthill-pro at caladin.urbancode.com   cc
> >>   Subject
> >> [Anthill-pro] Will anthillpro Supports C++ Build in Linux OS
> >>
> >>
> >>
> >>
> >> Hi Gurus,
> >>
> >> May i know weather anthillpro Supports C++ Builds in Linux OS? I have a
>
> >> requirement that the Tool should build C++ tarballs nightly and on
> local
> >> developer demand.
> >>
> >> Please guide me.
> >>
> >> Thanks
> >> Joe _______________________________________________
> >> Anthill-pro mailing list
> >> Anthill-pro at lists.urbancode.com
> >> http://lists.urbancode.com/mailman/listinfo/anthill-pro
> >>
> >>
> >>
> >> This e-mail, including attachments, may include confidential and/or
> >> proprietary information, and may be used only by the person or entity
> to
> >> which it is addressed. If the reader of this e-mail is not the intended
>
> >> recipient or his or her authorized agent, the reader is hereby notified
> >> that any dissemination, distribution or copying of this e-mail is
> >> prohibited. If you have received this e-mail in error, please notify
> the
> >> sender by replying to this message and delete this e-mail immediately.
> >>
> >> _______________________________________________
> >> Anthill-pro mailing list
> >> Anthill-pro at lists.urbancode.com
> >> http://lists.urbancode.com/mailman/listinfo/anthill-pro
> >>
> >>
> >>
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Anthill-pro mailing list
> > Anthill-pro at lists.urbancode.com
> > http://lists.urbancode.com/mailman/listinfo/anthill-pro
> >
>
> _______________________________________________
> Anthill-pro mailing list
> Anthill-pro at lists.urbancode.com
> http://lists.urbancode.com/mailman/listinfo/anthill-pro
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.urbancode.com/pipermail/anthill-pro/attachments/20070815/6a23a9fe/attachment-0001.htm