The pdbcopy command (http://msdn.microsoft.com/en-us/library/cc501198.aspx
) can apparently be used to strip a private PDB down to a public one.
If both were needed you could always have csc generate a full version,
and then have a simple pdbcopy plugin produce the public version. Of
course, you wouldn't even really need a pdbcopy plugin as the exec
plugin could do the trick. It simply might be a tad cleaner to have a
pdbcopy plugin.
I expect most readers already knew this, I simply failed to mention it
in the earlier post.
On Oct 19, 2008, at 9:00 AM, Brett Porter wrote:
On 19/10/2008, at 2:38 PM, James Carpenter wrote:
I think what really needs to happen is proper support for multiple
compilation settings (Think release and debug builds.). I believe
there is already a JIRA issue for this. I haven't really thought
this out, but I think the compiler plugin should be configurable to
create multiple compilation artifacts with different option values
and an associated classifier for each. Secondary artifacts like
PDB files would of course just be attached artifacts with an
appropriate classifier.
It is worth nothing, that PDB files can apparently be configured to
have more or less information. So called "private" PDB files have
a lot more details than "public" PDB files. Public PDB files
contain a subset of the information in a private PDB. The
information in a private PDB is apparently sufficiently detailed to
make reverse engineering/decompiling code much easier. When a
company releases a closed source library they will often release
public PDB files along with the library, but will keep private PDB
files for internal use. To further complicate things, I believe I
read one can configure private PDB files to have less information
than a typical PDB file but more than a public PDB file. Each of
these would likely need to correlate with their own classifier.
None of the above is really all that tricky.
Yep, it sounds about right to me.
The really tricky part will be how to deal with dependencies when
compiling, running unit tests, running the assembly plugin, etc.
It seems dependencies should have an implicit classifier based on
context. When a release assembly/dll is being built, maven should
probably use release versions of the dependencies (implicit release
classifier). When a debug assembly is being built, maven should
probably use debug versions of the project's dependencies. This is
to say, the implicit classifier of the dependencies should
correspond to the classifier associated with the compiler plugin
configuration being built. By using the appropriate command line
options it should be possible to concurrently build as many of
these different assembly types as desired. (Would this just be
different compiler plugin execution configurations?)
Yes, I think it would be dangerous for nmaven to start to inventing
solutions to things that belong in maven proper - having been down
that road before and seen the problems it leads to.
Generally, Maven just builds one thing at a time (so there is a
normal build, then a release profile, and maybe some other profile
for other scenarios). In this case, it seems you might default to
everything off, but then some may enable a full debug PDB in the
normal builds, and in release turn that off and publish a public PDB
instead.
If for any reason this requires multiple compilations you could add
extra executions, but that sounds odd - you should be able to get
the right set of options for your scenario and then package as
appropriate, and configure differently in different profiles for
different scenarios.
I believe this works out better for unit tests as well. Assembly
plugin generally takes what you tell it so should work in most
situations.
What you might want is to start flipping classifiers - debug info
builds add debug info for dependencies, and so on. This is a missing
capability in Maven right now (the corresponding Java use case is
the jdk14/15 builds that have jdk14/15 dependenceis). It's a
limitation in the classifier in that it does actually affect the
metadata, though at present it is considered not to.
I think nmaven is already using its own dependency resolver, so
everything should be quite tractable, but it may be a bit tricky to
sort out. If I was to attack it I would probably just have to
evolve the code until it smelled right. I don't think I would be
able to see all the way to the end solution when I started.
In trunk, nmaven uses the standard dependency resolver.
When building Java code maven doesn't really have to deal with any
of this sticky mess. It might be instructive to see how other non-
Java (C++?) related plugins are handling this.
There's a few different ways, but you're right - some of the
problems are similar.
Thanks!
Cheers,
Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
Sincerely,
James Carpenter
cell: 832-677-7247
email: [EMAIL PROTECTED]
