lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Vesse <rve...@dotnetrdf.org>
Subject Re: SPAM-HIGH: Re: Multi-targeting and .Net (WAS Outstanding issues for 3.0.3)
Date Tue, 10 Jul 2012 19:09:59 GMT
My workflow is typically to code to .Net 4.0 but I do tend to use
compilation symbols heavily during coding.  Especially if I'm coding
something I know is .Net 4.0 only (e.g. PLINQ) I'll put in the symbols and
the alternative code paths/throwing of unsupported errors as I code.

More often than not I end up just getting the .Net 4.0 build into a
working state, try to compile for other platforms and then go back and fix
any errors I find by adding the compilation symbols and relevant
fixes/workarounds.  This is particularly true of targeting
Silverlight/Windows Phone 7 where the framework is more limited or has
different method signatures/lacks constants/properties e.g. there is no
Encoding.ASCII on those platforms and thus it's hard to remember what will
and won't be supported there.

I also find it helpful to have one/more compatibility classes that are
specific to each target framework project and provide extension methods or
static helpers which emulate the missing behaviors I'd normally use.  In
some cases this avoids having to use compilation symbols at all since the
missing framework features on other versions of the platform are simply
provided by my compatibility classes when compiling for those platforms.

In terms of targeting with different dependencies each template file has
framework specific dependencies in it though I'm not sure if that's
something that Lucene.Net has to worry about though may start applying if
you want to build the contrib libraries against different Lucene.Net
versions

Rob

On 7/10/12 10:55 AM, "Christopher Currens" <currens.chris@gmail.com> wrote:

>Thanks Rob.  This was my almost exact solution to this problem, except
>mine
>just modifies the project file and saves a copy named *.35.csproj/sln.  It
>got a little more complicated, because I can't support Contrib.Spatial in
>.NET 3.5 without some hefty changes I didn't want to do, so there's
>(unfortunately) very specific, not really re-usable code, to detect that.
> We also have to add a conditional symbol to each project.  It all works
>good enough (read no errors) and generates .NET 3.5 solutions and project
>files that can be opened in Visual Studio or built via MSBuild.  I guess
>my
>larger concern is how it can affect the workflow, and since you have some
>experience maybe you can answer some of my questions.
>
>What is your workflow with building for all these different frameworks?
> More specifically, do you code for a certain framework and then just run
>the tool and hope that the rest compile (this would probably be *my*
>"genius" way of doing it)?  There are certainly nice features in .NET 4.0
>(Tasks, etc..) that I would prefer to use, so it would make sense to first
>write for that target, build the 3.5 projects and try and add conditionals
>for that.
>
>
>Thanks,
>Christopher
>
>On Mon, Jul 9, 2012 at 10:21 PM, Rob Vesse <rvesse@dotnetrdf.org> wrote:
>
>> Hey Chris
>>
>> For multi-targeted stuff with .Net I've built some stuff that uses a
>>small
>> executable and NAnt to generate project files which can then be compiled
>> with MSBuild.
>>
>> This technique is used extensively for dotNetRDF where we target up to 6
>> different framework profiles for some of our libraries.  Essentially it
>> takes a source project, a project template to populate and a resulting
>> project name you want to generate.  It also needs a relative path to
>> indicate where the source project lives in relation to the target
>>project.
>>
>> When it runs it goes through the source project file and for every
>> Compile/EmbeddedResource item which is directly in that project (I.e.
>>not
>> included via a Link) it adds a Link to that item to the target project
>> file.
>>
>> The target project file is literally a stub project file (generated in
>> Visual Studio with the target framework set appropriately and it's own
>> AssemblyInfo.cs), see
>> 
>>http://dotnetrdf.svn.sourceforge.net/viewvc/dotnetrdf/Trunk/Libraries/cor
>>e.
>> 
>>clientprofile/dotNetRDF.ClientProfile.csproj.template?revision=2252&view=
>>ma
>> rkup for an example template.
>>
>> See
>> 
>>http://dotnetrdf.svn.sourceforge.net/viewvc/dotnetrdf/Trunk/Build/ExportC
>>or
>> eContentsToTemplate/ for the actual tool
>>
>> For the NAnt scripts with example usages see
>> 
>>http://dotnetrdf.svn.sourceforge.net/viewvc/dotnetrdf/Trunk/Build/nant/do
>>tn
>> etrdf.build?revision=2252&view=markup - Look at the projectgen goals for
>> invocation examples and the compile targets for invoking MSBuild on the
>> end results.
>>
>> It may be somewhat clunky but it does work, I'm sure it can be adapted
>>to
>> your needs if you're interested - it's all open source
>>
>> Rob
>>
>> On 7/9/12 5:51 PM, "Christopher Currens" <currens.chris@gmail.com>
>>wrote:
>>
>> >I've got it working, compiling and all test passing...The only caveat
>>is
>> >that I'm not sure the best way to multi-target.  It doesn't really
>>work on
>> >a project level, so you'd have to create two separate projects, one for
>> >.NET 4 and the other for 3.5.  To aid me, I wrote a small tool that
>> >creates
>> >copies of all of the 4.0 projects and solutions to work against the 3.5
>> >framework.  Anyone have experience with multi-targeting like this?
>> >
>> >
>> >Thanks,
>> >Christopher
>> >
>> >On Mon, Jul 9, 2012 at 11:29 AM, Prescott Nasser
>> ><geobmx540@hotmail.com>wrote:
>> >
>> >>
>> >> Have at it.
>> >>
>> >> ----------------------------------------
>> >> > Date: Mon, 9 Jul 2012 11:20:06 -0700
>> >> > Subject: Re: Outstanding issues for 3.0.3
>> >> > From: currens.chris@gmail.com
>> >> > To: lucene-net-dev@lucene.apache.org
>> >> >
>> >> > If it's alright with you, I'll work on it a little bit in that
>>branch,
>> >> and
>> >> > see what kind of progress I can make, since I have some time right
>> >>now.
>> >> >
>> >> > On Mon, Jul 9, 2012 at 11:06 AM, Prescott Nasser
>> >><geobmx540@hotmail.com
>> >> >wrote:
>> >> >
>> >> > >
>> >> > > I made some progress on 480 - checked into the 3.5 branch, there
>>is
>> >> more
>> >> > > work to be done we could potentially move it to 3.0.3, but I put
>>it
>> >> into
>> >> > > 3.5 because I felt that we were closer to having this released,
>>and
>> >> adding
>> >> > > those changes would add a fair amount of change so close to the
>> >> release. I
>> >> > > can add it back to the schedule, though I'm mostly just doing
>> >> > > administrative work for the next two weeks though - I have a few
>> >> things I
>> >> > > have to take care of
>> >> > >
>> >> > > ----------------------------------------
>> >> > > > Date: Mon, 9 Jul 2012 10:21:42 -0700
>> >> > > > Subject: Re: Outstanding issues for 3.0.3
>> >> > > > From: currens.chris@gmail.com
>> >> > > > To: lucene-net-dev@lucene.apache.org
>> >> > > >
>> >> > > > The tests should all be fine now. We had a contributer, Luc
>> >> Vanlerberghe,
>> >> > > > who did a LOT of work for us, getting these last few difficult
>> >>bugs
>> >> out
>> >> > > of
>> >> > > > the way. He's responsible for half or more of the failing
tests
>> >>from
>> >> > > > LUCENENET-484 getting fixed, as well as LUCENE-493, with
the
>> >>culture
>> >> > > > sensitivity. Also, I think we should no longer get any culture
>> >> issues,
>> >> > > > since the tests that are marked as culture sensitive are
now
>>all
>> >>run
>> >> in
>> >> > > all
>> >> > > > installed cultures on the machine.
>> >> > > >
>> >> > > > I think CLS compliance is still important and should be
>>handled.
>> >>What
>> >> > > > about LUCENENET-480? I know that Prescott had done some work
on
>> >>this
>> >> and
>> >> > > I
>> >> > > > also know this was requested by several in the community.
I
>>would
>> >> love to
>> >> > > > see that make it into 3.0.3, and would be able to pick up
where
>> >> anyone
>> >> > > had
>> >> > > > left off or take part of it, if they don't have time to work
on
>> >>it.
>> >> In
>> >> > > > regards to LUCENENET-446, I agree that it is pretty much
>> >>complete. I
>> >> > > think
>> >> > > > I've looked several times at it to confirm most/all methods
>>have
>> >>been
>> >> > > > converted, so this week I'll do a final check and close it
out.
>> >> > > >
>> >> > > >
>> >> > > > Thanks,
>> >> > > > Christopher
>> >> > > >
>> >> > > > On Sun, Jul 8, 2012 at 12:28 PM, Simon Svensson
>><sisve@devhost.se
>> >
>> >> > > wrote:
>> >> > > >
>> >> > > > > The tests that failed when using culture=sv-se seems
fixed.
>> >> > > > >
>> >> > > > >
>> >> > > > > On 2012-07-08 20:44, Itamar Syn-Hershko wrote:
>> >> > > > >
>> >> > > > >> What's the status on the failing tests we had?
>> >> > > > >>
>> >> > > > >> On Sun, Jul 8, 2012 at 9:02 PM, Prescott Nasser
<
>> >> > > geobmx540@hotmail.com
>> >> > > > >> >wrote:
>> >> > > > >>
>> >> > > > >> Three issues left that I see:
>> >> > > > >>>
>> >> > > > >>>
>> >> > > > >>>
>> >> > > > >>> Fixing the build output, I did some work, but
I'm good on
>> >>this,
>> >> we
>> >> > > can
>> >> > > > >>> move the rest of work to 3.6
>> >> > > > >>> https://issues.apache.org/**jira/browse/LUCENENET-456<
>> >> > > https://issues.apache.org/jira/browse/LUCENENET-456>
>> >> > > > >>>
>> >> > > > >>>
>> >> > > > >>>
>> >> > > > >>> CLS Compliance
>> >> https://issues.apache.org/**jira/browse/LUCENENET-446
>> >> > > <https://issues.apache.org/jira/browse/LUCENENET-446>.
>> >> > > > >>> Are
>> >> > > > >>> we ok with this as for now? There are still
a good number
>>of
>> >> issues
>> >> > > > >>> where,
>> >> > > > >>> some we can't really fix (sbyte and volatile
are out of
>>scope
>> >> imo).
>> >> > > In a
>> >> > > > >>> similiar vein, our own code uses some obsolete
methods and
>>we
>> >> have a
>> >> > > lot
>> >> > > > >>> of
>> >> > > > >>> variable declared but never used warnings (mentally,
I
>>treat
>> >>most
>> >> > > warning
>> >> > > > >>> as an error)
>> >> > > > >>>
>> >> > > > >>>
>> >> > > > >>>
>> >> > > > >>> GetX/SetX -
>> >> https://issues.apache.org/**jira/browse/LUCENENET-470<
>> >> > > https://issues.apache.org/jira/browse/LUCENENET-470>.
>> >> > > > >>> I think
>> >> > > > >>> much of this has been removed, there are probably
some
>>pieces
>> >> that
>> >> > > left
>> >> > > > >>> (and we have a difference of opinion in the
group as well).
>> >> > > > >>>
>> >> > > > >>>
>> >> > > > >>>
>> >> > > > >>>
>> >> > > > >>>
>> >> > > > >>> I really think the only outstanding issue is
the CLS
>> >>compliance
>> >> one,
>> >> > > the
>> >> > > > >>> rest can be moved to 3.6. With CLS compliance
we have to
>>ask
>> >>if
>> >> we've
>> >> > > > >>> done
>> >> > > > >>> enough for that so far, or if more is needed.
I personally
>> >>would
>> >> > > like to
>> >> > > > >>> see us make any API changes now, with the 3.0.3
release,
>>but
>> >>if
>> >> we
>> >> > > are
>> >> > > > >>> comfortable with it, lets roll.
>> >> > > > >>>
>> >> > > > >>>
>> >> > > > >>>
>> >> > > > >>> What are your thoughts?
>> >> > > > >>>
>> >> > > > >>>
>> >> > > > >>>
>> >> > > > >>> ~P
>> >> > > > >>>
>> >> > > > >>>
>> >> > > > >>>
>> >> > > > >>>
>> >> > > > >>>
>> >> > > > >>> ------------------------------**----------
>> >> > > > >>>
>> >> > > > >>>> From: thoward37@gmail.com
>> >> > > > >>>> Date: Mon, 25 Jun 2012 10:34:37 -0700
>> >> > > > >>>> Subject: Re: Outstanding issues for 3.0.3
>> >> > > > >>>> To: lucene-net-dev@lucene.apache.**org<
>> >> > > lucene-net-dev@lucene.apache.org>
>> >> > > > >>>>
>> >> > > > >>>> Assuming we're talking about the packaging/filesystem
>> >>structure
>> >> in
>> >> > > the
>> >> > > > >>>> releases, the structure is a little of both
(ours vs
>> >> Apache's)...
>> >> > > > >>>> Basically, I went through most of the Apache
projects to
>>see
>> >>how
>> >> > > they
>> >> > > > >>>> packaged releases and developed a structure
that was very
>> >> similar
>> >> > > but
>> >> > > > >>>> encompassed everything we needed. So, it's
informed by the
>> >> > > organically
>> >> > > > >>>> emergent structures that ASF uses.
>> >> > > > >>>>
>> >> > > > >>>> -T
>> >> > > > >>>>
>> >> > > > >>>>
>> >> > > > >>>> On Mon, Jun 25, 2012 at 7:32 AM, Prescott
Nasser <
>> >> > > geobmx540@hotmail.com
>> >> > > > >>>> >
>> >> > > > >>>>
>> >> > > > >>> wrote:
>> >> > > > >>>
>> >> > > > >>>> I have no idea why I thought we were using
Nant.
>> >> > > > >>>>> I think it's just "our release structure".
I figured a
>> >>little
>> >> out
>> >> > > this
>> >> > > > >>>>>
>> >> > > > >>>> weekend, splitting the XML and .dll files
into separate
>> >> > > directories. The
>> >> > > > >>> documentation you have on the wiki was actually
pretty
>> >>helpful.
>> >> > > > >>>
>> >> > > > >>>> Whatever more you can add would be great
>> >> > > > >>>>>
>> >> > > > >>>>> ~P
>> >> > > > >>>>>
>> >> > > > >>>>> Date: Mon, 25 Jun 2012 10:04:21 -0400
>> >> > > > >>>>>> Subject: Re: Outstanding issues
for 3.0.3
>> >> > > > >>>>>> From: mherndon@wickedsoftware.net
>> >> > > > >>>>>> To: lucene-net-dev@lucene.apache.**org<
>> >> > > lucene-net-dev@lucene.apache.org>
>> >> > > > >>>>>>
>> >> > > > >>>>>> On Sat, Jun 23, 2012 at 1:38 AM,
Prescott Nasser <
>> >> > > > >>>>>>
>> >> > > > >>>>> geobmx540@hotmail.com>wrote:
>> >> > > > >>>
>> >> > > > >>>>
>> >> > > > >>>>>>> -- Task 470, a non-serious one,
is listed only because
>> >>it's
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>> mostly done
>> >> > > > >>>
>> >> > > > >>>> and
>> >> > > > >>>>>>>
>> >> > > > >>>>>>>> just need a few loose ends
tied up. I'll hopefully
>>have
>> >> time to
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>> take care
>> >> > > > >>>
>> >> > > > >>>> of that this weekend.
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>>
>> >> > > > >>>>>>> How many GetX/SetX are left?
I did a quick search for
>> >> 'public *
>> >> > > > >>>>>>>
>> >> > > > >>>>>> Get*()'
>> >> > > > >>>
>> >> > > > >>>> Most of them looked to be actual methods
- perhaps a few
>>to
>> >> replace
>> >> > > > >>>>>>>
>> >> > > > >>>>>>>
>> >> > > > >>>>>>> -- Task 446 (CLS Compliance),
is important, but
>>there's no
>> >> way we
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>> can get
>> >> > > > >>>
>> >> > > > >>>> this done quickly. The current state of
this issue is that
>> >>all
>> >> of
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>> the
>> >> > > > >>>
>> >> > > > >>>> names of public members are now compliant.
There are a few
>> >> things
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>> that
>> >> > > > >>>
>> >> > > > >>>> aren't, the use of sbyte (particularly those
related to
>>the
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>> FieldCache)
>> >> > > > >>>
>> >> > > > >>>> and
>> >> > > > >>>>>>>
>> >> > > > >>>>>>>> some conflicts with *protected
or internal* fields
>>(some
>> >> with
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>> public
>> >> > > > >>>
>> >> > > > >>>> members). Opinions on this one will be appreciated
the
>>most.
>> >>My
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>> opinion
>> >> > > > >>>
>> >> > > > >>>> is that we should draw a line on the amount
of CLS
>> >>compliance to
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>> have in
>> >> > > > >>>
>> >> > > > >>>> this release, and push the rest into 3.5.
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>>
>> >> > > > >>>>>>>
>> >> > > > >>>>>>> I count roughly 53 CLS compliant
issues. the sbyte
>>stuff
>> >> will run
>> >> > > > >>>>>>>
>> >> > > > >>>>>> into
>> >> > > > >>>
>> >> > > > >>>> trouble when you do bit shifting (I ran
into this issue
>>when
>> >> trying
>> >> > > > >>>>>>>
>> >> > > > >>>>>> to do
>> >> > > > >>>
>> >> > > > >>>> this for 2.9.4. I'd like to see if we can't
get rid of the
>> >> easier
>> >> > > > >>>>>>>
>> >> > > > >>>>>> stuff
>> >> > > > >>>
>> >> > > > >>>> (internal/protected stuff). I would not
try getting rid of
>> >> sbyte or
>> >> > > > >>>>>>> volatile for thile release.
It's going to take some
>> >>serious
>> >> > > > >>>>>>>
>> >> > > > >>>>>> consideration
>> >> > > > >>>
>> >> > > > >>>> to get rid of those
>> >> > > > >>>>>>>
>> >> > > > >>>>>>>
>> >> > > > >>>>>>> -- Improvement 337 - Are we
going to add this code (not
>> >> present
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>> in java)
>> >> > > > >>>
>> >> > > > >>>> to
>> >> > > > >>>>>>>
>> >> > > > >>>>>>>> the core library?
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>>
>> >> > > > >>>>>>>
>> >> > > > >>>>>>> I'd skip it and re-evaluate
the community desire for
>>this
>> >>in
>> >> 3.5.
>> >> > > > >>>>>>>
>> >> > > > >>>>>>>
>> >> > > > >>>>>>> -- Improvement 456 - This is
related to builds being
>> >>output
>> >> in
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>> Apache's
>> >> > > > >>>
>> >> > > > >>>> release format. Do we want to do this for
this release?
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>> I looked into this last weekend
- I'm terrible with
>>Nant,
>> >>so
>> >> I
>> >> > > > >>>>>>>
>> >> > > > >>>>>> didn't get
>> >> > > > >>>
>> >> > > > >>>> anywhere. It would be nice to have, but
I don't think I'll
>> >> figure
>> >> > > > >>>>>>>
>> >> > > > >>>>>> it out.
>> >> > > > >>>
>> >> > > > >>>> If Michael has some time to maybe make the
adjustment, he
>> >>knows
>> >> > > > >>>>>>>
>> >> > > > >>>>>> these
>> >> > > > >>>
>> >> > > > >>>> scripts best. If not I'm going to look into
it, but I
>>don't
>> >>call
>> >> > > > >>>>>>>
>> >> > > > >>>>>> this a
>> >> > > > >>>
>> >> > > > >>>> show stopper - either we have it or we don't
when the
>>rest is
>> >> done.
>> >> > > > >>>>>>>
>> >> > > > >>>>>>> With some Flo Rida and expresso
shots, anything is
>> >>possible.
>> >> > > > >>>>>>
>> >> > > > >>>>>> Did we switch to Nant?
>> >> > > > >>>>>>
>> >> > > > >>>>>> I saw the jira ticket for this.
Is there an official
>>apache
>> >> > > release
>> >> > > > >>>>>> structure or this just our* apache
release structure
>>that
>> >>we
>> >> are
>> >> > > > >>>>>>
>> >> > > > >>>>> using?
>> >> > > > >>>
>> >> > > > >>>> Can I take the latest release and use that
to model the
>> >> structure
>> >> > > you
>> >> > > > >>>>>>
>> >> > > > >>>>> guys
>> >> > > > >>>
>> >> > > > >>>> want?
>> >> > > > >>>>>>
>> >> > > > >>>>>> @Prescott declarative xml build
scripts are a pita in
>> >>general.
>> >> > > only
>> >> > > > >>>>>>
>> >> > > > >>>>> reason
>> >> > > > >>>
>> >> > > > >>>> we're using this over powershell or a scripting
language
>>is
>> >>that
>> >> > > mono
>> >> > > > >>>>>> supports it and most .NET devs have
it already
>>installed.
>> >> > > > >>>>>>
>> >> > > > >>>>>> I'll spend some more time documenting
it so that others
>>can
>> >> work
>> >> > > on
>> >> > > > >>>>>>
>> >> > > > >>>>> it and
>> >> > > > >>>
>> >> > > > >>>> even refactor it.
>> >> > > > >>>>>>
>> >> > > > >>>>>>
>> >> > > > >>>>>>>
>> >> > > > >>>>>>>
>> >> > > > >>>>>>>
>> >> > > > >>>>>>> ~P
>> >> > > > >>>>>>>
>> >> > > > >>>>>>
>> >> > > > >
>> >> > > > >
>> >> > >
>> >> > >
>> >>
>> >>
>>
>>
>>
>>
>>





Mime
View raw message