On Nov 9, 2008, at 6:43 AM, Max Bowsher wrote:
Alan D. Cabrera wrote:
On Nov 8, 2008, at 2:55 PM, Max Bowsher wrote:
The difficulty is that there is no standard on how to manage the
multitude of flavours of native binaries that are possible.
For example, there's architecture and OS that need to be
considered, but
for all but then you start to get things like C library version
being
involved. If you are looking to do anything with apr-util as well
as apr
itself, then the problem explodes with the number of extra
dependencies.
I was thinking that the artifact name could be
apr-<osname>-<processor>
e.g. apr-linux-x86_64. Or we can have a more general
apr-<osname>-<processor>-<configuration>
where configuration is a token that represents a particular
configuration of options, e.g. apr-msdos-8086-aztecc.
This is the right place to start (though may I suggest <arch>-<os>
rather than <os>-<arch>, for consistency with the prior art that I'm
aware of, namely autoconf-style system names and the
freehep-nar-maven-plugin).
(There's also the question of what architecture/processor naming
scheme
to use - amd64 vs. x86_64, i386 vs. i586 vs. i686, etc. - "dpkg
--print-architecture", "uname -m", and Java's os.arch manage to be
inconsistent more often than not.)
I'm not sure that we need to choose one over the other. Let me ask
you this, why would we need fine grained detail such as "i386 vs.
i586 vs. i686"? Is that really necessary?
More of an issue, though, is the dependencies on other system
libraries,
and what versions thereof, the APR artifact may have. For example, the
APR shared lib on my Ubuntu system depends on glibc >= 2.4, and
libuuid1.
This means it won't work on Debian etch / Ubuntu dapper, for
example, or
other distros of similar age, nor would it work if libuuid1 was
missing
- quite unlikely, I admit, but possible.
Whilst these dependencies are not *that* onerous, especially once
Debian
lenny succeeds etch as stable, they do illustrate the problem.
I'm not sure why APR would allow such a system dependancy. APR is
supposed to make application developers' lives easier. Why would I
have to worry about libuuid1 missing? I'm new to APR and am getting
my head around what it will and will not do for me.
In particular, beware that the specific version of glibc required
isn't
something determined just by the apr source, but by the version being
compiled against, and even the compiler flags being used.
For example, if the chosen option was to force a glibc 2.3.x
compatible
build, I believe that forcing HAVE_PTHREAD_MUTEX_ROBUST to off and
setting the -fno-stack-protector compiler option would disable the
features that currently cause us to require glibc 2.4 at run-time if
present at compile-time.
That might be a viable option for producing an adequately compatible
binary for Maven deployment.
Version 2.3.x strikes me as really old. Unless I'm missing something,
we, in my case, won't have to deal with that corner case.
Leaving aside the compatibility issues for a moment, what is the
intended method for Maven projects to depend on the APR artifacts?
Would
they need to specify a specific flavour hardcoded in their POM
(potentially conditionalized with a long series of profiles, though
this
likely wouldn't be flexible enough to do a completely satisfactory
job)?
Or is there a better way that I'm unaware of?
I think in this case, my case, we only need to worry about a few stock
configurations, e.g. Linux and Windows. For me that would handle
99.9% of my universe. More exotic configurations can use the naming
conventions that we are currently working out and publish on an as
needed basis; I don't anticipate this happening often.
To give some more color to what I want to do, I want to make OSGi
bundles for APR. I would use OSGi's native code loading mechanism to
"dispatch" the correct library.
I have to admit that "wrinkles" that you presented above seem to be
rare corner cases in my world.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
