Good point. Source RPM handles this with options you can pass to the
rpmbuild command. Maven could have either command line or configuration
options to do the same.

From
http://www.rpm.org/max-rpm-snapshot/s1-rpm-multi-build-install-detection.html
,

"The *--buildarch* and *--buildos* options can be used to set the build-time
architecture and operating system rather than relying on RPM's automatic
detection capabilities. These options are added to a normal RPM build
command. One important point to remember is that, although RPM does try to
find the specified architecture name, it does no checking as to the sanity
of the entered architecture or operating system. For example, if you enter
an entirely fictional operating system, RPM will issue a warning message,
and then happily build a package for it."

This brings up an interesting idea. Rather than building the infrastructure
into Maven to detect OS and architecture information, perhaps Maven could
delegate this to rpm, at least on Linux. RPM is the package format defined
for the Linux Standard Base, although it mentions the standard includes only
the rpm package format and not the rpm command or specific rpm macros. In
practice, this might not be a big deal. Most or all distros might use the
same rpm command options and a small set of standard macros.

http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/swinstall.html
http://www.linuxbase.org/talks/lca2005/img52.html

Just an idea for trying to reduce the effort to support this and unnecessary
duplication of functionality.

Roger

On 11/1/05, Sean Hennessy <[EMAIL PROTECTED]> wrote:
>
> If one considers an alternative use case scenario where a single host
> (build server) is cross compiling for multiple targets.
> Then would not the maven "sense the machine architecture" solution would
> only support one target environment?
> Perhaps a mechanism for management of iterative profiles in order to
> target environment.
>
> -----Original Message-----
> From: Roger Hoover [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 01, 2005 12:28 PM
> To: Maven Users List
> Subject: Re: Building C++ projects with Maven (2)
>
>
> The concern I would have with this is that you have the same logical
> package (let's say apr 1.2.2) built for different architectures needing
> to have a different groupId or artifactId for each architecture type.
> Unless the groupId or artifactId is constructed dynamically, poms that
> depend on a native artifact have to depend on a specific architecture
> type. I think it would be nice to write generic poms that depend on just
> the logical package (apr 1.2.2 instead of apr 1.2.2 x86_64) and have
> maven sense the machine architecture (and OS) and fetch the correct
> native artifact.
>
> Roger
>
> On 11/1/05, dan tran <[EMAIL PROTECTED]> wrote:
> >
> > You can use groupId for platform specific or add platform specific
> > string to your artifact id.
> > -D
> >
> >
> > On 11/1/05, Chris Berry <[EMAIL PROTECTED]> wrote:
> > >
> > > This brings up a bigger question; How does maven want to handle OS
> > > information in the repo?? To be successful w/ other languages like
> > > C,
> > the
> > > repo will need to delineate information such as "i586" and "linux".
> > > Are these to be rolled into the groupId?? That doesn't smell right.
> > > Seems
> > that
> > > we may need new Artifact Resolvers that understand this sort of info
>
> > > natively and can transparently supply the the correct pieces to the
> > > URL.
> > >
> > > Cheers,
> > > -- Chris
> > >
> > > On 11/1/05, dan tran <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi David,
> > > > There is a work in progress for native-maven-plugin
> > > > http://svn.mojo.codehaus.org/trunk/mojo/maven-native/
> > > > You can build it and take a look at some doc.
> > > > -Dan
> > > >
> > > >
> > > > On 11/1/05, David Jackman <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > I've just found out that I'm going to need to expand our Maven
> > > > > build process to include several C++ project (which I believe
> > > > > are built
> > > using
> > > > > gcc). I seem to remember seeing some traffic on this list from
> > people
> > > > > doing this sort of thing (which I promptly ignored because I
> > > > > wasn't
> > at
> > >
> > > > > the time). Can anyone offer some insight on how you got this to
> > > > > work and how you overcame the problems that came up? What
> > > > > plugins are available to build this way and do they do
> > > > > everything you need? Are
> > > you
> > > > > able to have dependencies in the Maven repository and have the
> > > > > build
> > > use
> > > > > them from there (similar to .jar dependencies)? How do you
> > > > > access
> > the
> > > > > header files, possible library, and runtime library for the
> > different
> > > > > portions of the build? Is there a mini guide for this kind of
> > project
> > > > > in the works?
> > > > >
> > > > > Thanks,
> > > > > ..David..
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to