[nant-dev] Params vs properties redux was: Nant .85 not working with Draco.Net
This seems to be causing a lot of grief. I'm really leaning towards
having a list of elements at the project level and allowing
those and only those values to be passed on the commandline. I'm not
sure how feasible that would be with the way we pass properties to
nested builds but I think it would simplfy things a lot and add extra
benefits. For example:
...
params would be the equivalent of c#'s args[] array thats passed to main
and similarly would be readonly. Because they are seperate from
properties its clear that they have pass by value semantics. The
default attribute allows you to use a default if a value isn't passed on
the commandline without haveing to do the non-intuitive
overwrite="false" mojo that is required now - similar to languages that
allow default values for function paramaters. The description would be
output when you do a nant -projecthelp further documenting the build file.
If you want a writable value based on a param you would set a new
property - the same as you would in c# code with pass by value method
arguments. Similarly it probably makes sense to have params and
properties in the same namespace so you coulndn't create a property with
the same name as an existing param.
Ian
Merrill Cornish wrote:
Unfortunately, the property task's overwrite attribute can't overwrite a readonly
property--according to the documentation.
So, if you are passing a command line argument into the NAnt 0.85 script and you want to munge that value internally, then you will have to create a second property initialized to the command line property value, then munger this second property.
Of course, if the command line argument wasn't specified, then you can detect that in
the NAnt script with not property::exists('propertyName') then set propertyName to its
default value.
Merrill
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
___
Nant-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-users
--
Ian MacLean, Developer,
ActiveState, a division of Sophos
http://www.ActiveState.com
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: Add support for multiple filesets to the task.
You can always just use multiple invocations of the task Ian Gert Driesen wrote: Hi Felice, I think we should actually tackle this in general : I'm pretty sure there are more tasks where support for multiple filesets could be useful. However, this should be done post 0.85 ... Gert - Original Message - From: "Felice Vittoria" <[EMAIL PROTECTED]> To: "Gert Driesen" <[EMAIL PROTECTED]> Sent: Friday, August 20, 2004 9:57 PM Subject: Add support for multiple filesets to the task. Gert, I was wondering what the status of "Add support for multiple filesets to the task" is. I noticed in the Release Plan that it's pending. If it's not going in Nant 0.85 will it be going in a future release? Thanks, Felice --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers -- Ian MacLean, Developer, ActiveState, a division of Sophos http://www.ActiveState.com --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Re: Add support for multiple filesets to the task.
Hi Felice, I think we should actually tackle this in general : I'm pretty sure there are more tasks where support for multiple filesets could be useful. However, this should be done post 0.85 ... Gert - Original Message - From: "Felice Vittoria" <[EMAIL PROTECTED]> To: "Gert Driesen" <[EMAIL PROTECTED]> Sent: Friday, August 20, 2004 9:57 PM Subject: Add support for multiple filesets to the task. Gert, I was wondering what the status of "Add support for multiple filesets to the task" is. I noticed in the Release Plan that it's pending. If it's not going in Nant 0.85 will it be going in a future release? Thanks, Felice --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: install targets
Gert Driesen wrote: - Original Message - From: "Ian MacLean" <[EMAIL PROTECTED]> To: "Gert Driesen" <[EMAIL PROTECTED]> Cc: "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]> Sent: Friday, August 20, 2004 11:44 AM Subject: Re: [nant-dev] Re: install targets The current layout is already confusing. How many "I downloaded version x of nant but the test failed when building" emails do we get - to which we reply "you don't need to build - its already there". If there is no makefile or NAnt.build in the binary distribution then this won't happen. But we do include a shell script for installing NAnt (and creating a wrapper script on linux) in the binary distribution ? yes I think so. I mean we could get away with using a small install.build file. Yeah I know I know - I just said in a previous mail that build/makefiles aren't necessarily the best choice for installers but it would be easy to write and it would be X-platform. PS. Have you have looked into creating an RPM for NAnt ? No - If I get a chance I'd like to - or if someone out there with rpm building skills would like to volunteer - that would be great too. Ian --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] [ nant-Bugs-969593 ] Solution task fails to guess outputpath
Bugs item #969593, was opened at 2004-06-09 15:27 Message generated for change (Comment added) made by drieseng You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402868&aid=969593&group_id=31650 Category: Tasks Group: 0.85 Status: Open Resolution: None Priority: 5 Submitted By: Thibaut Barrère (tbarrere) Assigned to: Nobody/Anonymous (nobody) Summary: Solution task fails to guess outputpath Initial Comment: symptom : when building a solution (attached here with the build file) using the solution task, I get the following output : OUTPUTBEGIN NAnt 0.85 (Build 0.85.1619.0; net-1.1.win32; nightly; 07/06/2004) Copyright (C) 2001-2004 Gerry Shaw NAnt Team Buildfile: file:///C:/workingpatches/PathCombine/default.build Target(s) specified: build build: [solution] Starting solution build. BUILD FAILED INTERNAL ERROR System.ArgumentNullException: Value cannot be null. Parameter name: path2 at System.IO.Path.Combine(String path1, String path2) at NAnt.VSNet.VcConfiguration.get_OutputPath() in c:\BuildServer\Tools\nant\src\NAnt.VSNet\VcConfiguration.cs:line 154 at NAnt.VSNet.ProjectBase.GetOutputPath(String configuration) in c:\BuildServer\Tools\nant\src\NAnt.VSNet\ProjectBase .cs:line 178 at NAnt.VSNet.Solution.GetDependenciesFromProjects() in c:\BuildServer\Tools\nant\src\NAnt.VSNet\Solution.cs:line 594 at NAnt.VSNet.Solution..ctor(FileInfo solutionFile, ArrayList additionalProjects, ArrayList referenceProjects, TempFi leCollection tfc, SolutionTask solutionTask, WebMapCollection webMaps, FileSet excludesProjects, DirectoryInfo outputDir , GacCache gacCache) in c:\BuildServer\Tools\nant\src\NAnt.VSNet\Solution.cs:line 131 at NAnt.VSNet.Tasks.SolutionTask.ExecuteTask() in c:\BuildServer\Tools\nant\src\NAnt.VSNet\Tasks\SolutionTask.cs:line 365 at NAnt.Core.Task.Execute() in c:\BuildServer\Tools\nant\src\NAnt.Core\Task.cs:line 176 at NAnt.Core.Target.Execute() in c:\BuildServer\Tools\nant\src\NAnt.Core\Target.cs:line 249 at NAnt.Core.Project.Execute(String targetName, Boolean forceDependencies) in c:\BuildServer\Tools\nant\src\NAnt.Core \Project.cs:line 870 at NAnt.Core.Project.Execute() in c:\BuildServer\Tools\nant\src\NAnt.Core\Project.cs:line 827 at NAnt.Core.Project.Run() in c:\BuildServer\Tools\nant\src\NAnt.Core\Project.cs:line 895 Please send bug report to [EMAIL PROTECTED] Total time: 0.2 seconds. OUTPUTEND investigation : i discovered this in the vcproj file (which I did not manually edit myself) .vcproj extract -- (...) (...) -- end of extract - vs.net doesn't always set the OutputFile attribute on VCLibrarianTool, and seems to default internally to the other configuration in this case. The project compiles fine under VS.Net 2003. consequence : the solution task fails to guess the outputpath through current configuration VCLibrarianTool. suggestion : defaults to another configuration vclibrarian tool (such as release, but what to do when there are more configurations, or no more "release" configuration ?) Thibaut Barrère -- >Comment By: Gert Driesen (drieseng) Date: 2004-08-20 16:46 Message: Logged In: YES user_id=707851 Ping ! -- Comment By: Gert Driesen (drieseng) Date: 2004-08-11 20:05 Message: Logged In: YES user_id=707851 Can you try using a (very) recent nightly build (http://nant.sourceforge.net/nightly/builds) ? Thanks ! -- Comment By: Darwin Dan Boyle (ddboyle945) Date: 2004-07-14 22:10 Message: Logged In: YES user_id=742907 I have also had this problem, I have a temporary workaround, and have looked at the Nant source code. I'm using NAnt 0.84 release. I tried the 7/14/2004 test build, and it didn't resolve this problem. To recreate the problem. Go into the MS Visual Studio .NET 2003 IDE, select File...New Project... and create an ATL .dll project (unmanaged). In our case, lets create a project called Binky. Hit enter through the rest of the defaults to have the project created on your hard drive. Notice that there are TWO .vcproj files created, one for the .dll (Binky.vcproj), and another for the proxy/stub of this DLL (BinkyPS.vcproj). The proxy/stub .vcproj is the one that fails in Nant with this error. As a work around, you can edit the .sln file with a text editor, and delete the lines containing the Project...EndProject for BinkyPS (and everything in between). The other project will work. This workaround works for me because I don't care about a COM proxy/stub (and I suspect most people don't care about the proxy/stub)... After looking at the source for src\Nant.VSNet\vcconfiguration.cs, around line 113 (I'm using 0.84 release), the code is trying to get a OutputFile from
[nant-dev] [ nant-Bugs-948243 ] Satellite resource assemblies reference bug
Bugs item #948243, was opened at 2004-05-05 08:27 Message generated for change (Comment added) made by drieseng You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402868&aid=948243&group_id=31650 Category: Tasks Group: 0.85 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jo (jo-tmbamf) >Assigned to: Gert Driesen (drieseng) Summary: Satellite resource assemblies reference bug Initial Comment: I am having a problem with the following scenario: I have one class library with a resource file contained in it: translations.en-us.resx. When I compile it (using vs.net) I get 2 dll files: - Translations.dll - en-US/Translations.resources.dll (notice that this dll is in a subfolder) I also have a web project, which has a reference to Translations.dll. When I compile the web project (using vs.net again) I get in my bin folder both the Translations.dll and en-US/Translations.resources.dll. However, when I compile the webproject with nant (using the solution task) I do not get "en- US/Translations.resources.dll" in my bin folder. I do not get any warnings or errors from the compiler either. -Jo ps. the attached repro uses a windows app instead of a web app, the bug remains the same of course. -- >Comment By: Gert Driesen (drieseng) Date: 2004-08-20 16:45 Message: Logged In: YES user_id=707851 This issue is now completely fixed in cvs. Thanks for the report ! -- Comment By: Jo (jo-tmbamf) Date: 2004-05-24 08:43 Message: Logged In: YES user_id=1035504 Thx! -- Comment By: Gert Driesen (drieseng) Date: 2004-05-15 10:01 Message: Logged In: YES user_id=707851 I fixed the second part of the bug report, meaning NAnt does not pick up a change in a resource file. -- Comment By: Jo (jo-tmbamf) Date: 2004-05-10 15:18 Message: Logged In: YES user_id=1035504 Related to this bug: 1. Run nant --> both projects are compiled 2. Edit the resource file (for example, change a key/value pair) 3. Run nant again --> nothing is recompiled, nant did not pick up the change in the resource file. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402868&aid=948243&group_id=31650 --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] [ nant-Bugs-997897 ] OutOfMemoryException runing many large ZIP tasks
Bugs item #997897, was opened at 2004-07-26 10:55 Message generated for change (Comment added) made by drieseng You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402868&aid=997897&group_id=31650 Category: Tasks Group: 0.8.4.0 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: ZN (girt) Assigned to: Gert Driesen (drieseng) Summary: OutOfMemoryException runing many large ZIP tasks Initial Comment: if many ZIP tasks folow each other then after each ZIP task memory is not released. And when SC is out of memory, error message is displayed "Exception of type System.OutOfMemoryException was thrown." NAnt 0.84 (Build 0.84.1455.0; net-1.0.win32; release; 26.12.2003) -- >Comment By: Gert Driesen (drieseng) Date: 2004-08-20 12:45 Message: Logged In: YES user_id=707851 I've just uploaded a new nightly build. Please reopen this bug report if the problem persists. -- Comment By: Gert Driesen (drieseng) Date: 2004-08-19 10:41 Message: Logged In: YES user_id=707851 I didn't yet upload a new nightly build ... that why I said "next nightly build" :-) I'll update the bug report when I've uploaded a new nightly build. -- Comment By: ZN (girt) Date: 2004-08-19 10:37 Message: Logged In: YES user_id=1091317 nope, still the same problem with NAnt 0.85 (Build 0.85.1690.0; net-1.0.win32; nightly; 17.08.2004) -- Comment By: Gert Driesen (drieseng) Date: 2004-08-19 09:18 Message: Logged In: YES user_id=707851 This is now fixed in cvs. Try using the next nightly build (http://nant.sourceforge.net/nightly/builds) or wait for the 0.85 release. Thanks for the report ! -- Comment By: Gert Driesen (drieseng) Date: 2004-08-02 14:19 Message: Logged In: YES user_id=707851 We've recently upgraded to a newer version of #ziplib, can you try to reproduce this issue using a recent nightly build (http://nant.sourceforge.net/nightly/builds) ? Thanks ! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402868&aid=997897&group_id=31650 --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: install targets
- Original Message - From: "Ian MacLean" <[EMAIL PROTECTED]> To: "Gert Driesen" <[EMAIL PROTECTED]> Cc: "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]> Sent: Friday, August 20, 2004 11:44 AM Subject: Re: [nant-dev] Re: install targets Gert Driesen wrote: Ian, I guess these was somehow a misunderstanding, but in the README.TXT you actually added a section called "Compliation and installation" in which you provide these instructions .. sure - then that should probably be "Compliation and installation of a source distribution" with a seperate "Installation of a binary distribution" section Yes, that should make it more clear ... or we provide seperate README's for source and binary. Yes, that might be better ... or installing the binary release should be self-explanatory Previously there were *no* instructions at all for building - thats why I added them. Yeah, I know ... and its not because I have questions or remarks that I don't appreciate the effort ... . These could easily be mistaken for instructions to install official releases ... Well - it quite clearly says "compilation" - if the official binary release doesn't contain source or a NAnt.build file (which it shouldn't) then users can hardly compile by accident can they ? I have the greatest confidence in the users, I'm pretty sure they can do just about everything but not that ;-) lol Currently, we only provide one means of "installing" NAnt (meaning using "make install" from the source distribution), so users are very likely to use that to install official distributions too (meaning they'll download and install the source distribution, while they should in fact use the binary distribution) ... ok - well then lets split into source and binary distros as soon as possible. The current layout is already confusing. How many "I downloaded version x of nant but the test failed when building" emails do we get - to which we reply "you don't need to build - its already there". If there is no makefile or NAnt.build in the binary distribution then this won't happen. But we do include a shell script for installing NAnt (and creating a wrapper script on linux) in the binary distribution ? Gert PS. Have you have looked into creating an RPM for NAnt ? --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: install targets
Gert Driesen wrote:
Ian,
I guess these was somehow a misunderstanding, but in the README.TXT
you actually added a section called "Compliation and installation" in
which you provide these instructions ..
sure - then that should probably be "Compliation and installation of a
source distribution" with a seperate
"Installation of a binary distribution" section
or we provide seperate README's for source and binary. Previously there
were *no* instructions at all for building - thats why I added them.
. These could easily be mistaken for instructions to install official
releases ...
Well - it quite clearly says "compilation" - if the official binary
release doesn't contain source or a NAnt.build file (which it shouldn't)
then users can hardly compile by accident can they ?
Currently, we only provide one means of "installing" NAnt (meaning
using "make install" from the source distribution), so users are very
likely to use that to install official distributions too (meaning
they'll download and install the source distribution, while they
should in fact use the binary distribution) ...
ok - well then lets split into source and binary distros as soon as
possible.
The current layout is already confusing. How many "I downloaded version
x of nant but the test failed when building" emails do we get - to which
we reply "you don't need to build - its already there". If there is no
makefile or NAnt.build in the binary distribution then this won't happen.
So we should make it very cler that this is not the recommended way to
install official releases of NAnt ...
of course.
Ian
Gert
- Original Message - From: "Ian MacLean" <[EMAIL PROTECTED]>
To: "Gert Driesen" <[EMAIL PROTECTED]>
Cc: "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]>
Sent: Friday, August 20, 2004 10:51 AM
Subject: Re: [nant-dev] Re: install targets
Gert Driesen wrote:
Ian,
After giving it some more thought, I think the "install" target of
the makefile should install the pre-built binaries and docs for
official NAnt distributions, not and rebuild the binaries from
source. We went to a lot of trouble in order to have a single
binary distribution, and I'd hate to see all that effort go to waste.
I disagree - this goes against how every other open source project
packages their distribution.
As I said before - its a source distribution that happens to
include pre built binaries *not* a binary distribution.
I actually consider it to be a binary distribution that happens to
include the source ;-)
thats the problem - right now we are a bit of both - thats what we
need to change.
I just don't understand why I went through all the trouble to allow
us to have a single binary distribution that can still take
advantage of framework-specific assemblies, if we instruct users to
build a framework specific version of NAnt.
we don't instruct them to do this -- that the point - we don't
instruct them to do anything but quite often they *do* build it
because there is a buildfile/make file and we never really provided
proper installation instructions.
Quite a while ago, we did agree that we should have a single binary
distribution that would work on all supported CLR's out-of-the-box,
right ? And now that we have it, we'd go back to having a
framework-specific binary install (with only very limited docs on
linux) ... not sure I understand the reason behind this ...
no - completely incorrect. The install target is *not* a substitute
for a binary installer. Its a convenience for when you build from
source. Its not meant to used as the installer for an end user.
What we should have (in my opinion) is :
- a source only distribution (containing only the binaries
necessary to build NAnt)
- a full binary distribution which would work on all supported
CLR's and platforms (this would be offered as a zip file or tar)
- an RPM release for linux
- an installer release for Windows
These last two would also install a full binary distribution
ofcourse ...
I totally agree. I thought thats what I basically proposed.
Also, the install targets in the NAnt build file should no longer
depend on other build/doc targets (but they should just install
whatever files are available in ${build.dir} (limited to bin, doc
and examples directories). The dependency on other NAnt build
target should be taken care of in the makefile.
why is that ? sure you'd want to install somthing thats built --
isn't that the point ? if you do a make install with most OSS
projects it will build first if its not up to date.
Yes, for source distributions that is But users cannot always
build a version of NAnt that is identical to what we want
distribute, while they still expect it to be ...
sure - again we are cross purposes -- Makefile is for building from
source, somthing else for a binary distribution.
For example :
Let's say we have an assembly that is Mono-specific. If we
encourage users to build NAnt from source, then users th
Re: [nant-dev] Re: install targets
Ian,
I guess these was somehow a misunderstanding, but in the README.TXT you
actually added a section called "Compliation and installation" in which you
provide these instructions ... These could easily be mistaken for
instructions to install official releases ...
Currently, we only provide one means of "installing" NAnt (meaning using
"make install" from the source distribution), so users are very likely to
use that to install official distributions too (meaning they'll download and
install the source distribution, while they should in fact use the binary
distribution) ...
So we should make it very cler that this is not the recommended way to
install official releases of NAnt ...
Gert
- Original Message -
From: "Ian MacLean" <[EMAIL PROTECTED]>
To: "Gert Driesen" <[EMAIL PROTECTED]>
Cc: "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]>
Sent: Friday, August 20, 2004 10:51 AM
Subject: Re: [nant-dev] Re: install targets
Gert Driesen wrote:
Ian,
After giving it some more thought, I think the "install" target of the
makefile should install the pre-built binaries and docs for official
NAnt distributions, not and rebuild the binaries from source. We went
to a lot of trouble in order to have a single binary distribution, and
I'd hate to see all that effort go to waste.
I disagree - this goes against how every other open source project
packages their distribution.
As I said before - its a source distribution that happens to include pre
built binaries *not* a binary distribution.
I actually consider it to be a binary distribution that happens to
include the source ;-)
thats the problem - right now we are a bit of both - thats what we need to
change.
I just don't understand why I went through all the trouble to allow us to
have a single binary distribution that can still take advantage of
framework-specific assemblies, if we instruct users to build a framework
specific version of NAnt.
we don't instruct them to do this -- that the point - we don't instruct
them to do anything but quite often they *do* build it because there is a
buildfile/make file and we never really provided proper installation
instructions.
Quite a while ago, we did agree that we should have a single binary
distribution that would work on all supported CLR's out-of-the-box, right
? And now that we have it, we'd go back to having a framework-specific
binary install (with only very limited docs on linux) ... not sure I
understand the reason behind this ...
no - completely incorrect. The install target is *not* a substitute for a
binary installer. Its a convenience for when you build from source. Its
not meant to used as the installer for an end user.
What we should have (in my opinion) is :
- a source only distribution (containing only the binaries necessary
to build NAnt)
- a full binary distribution which would work on all supported CLR's
and platforms (this would be offered as a zip file or tar)
- an RPM release for linux
- an installer release for Windows
These last two would also install a full binary distribution ofcourse ...
I totally agree. I thought thats what I basically proposed.
Also, the install targets in the NAnt build file should no longer
depend on other build/doc targets (but they should just install
whatever files are available in ${build.dir} (limited to bin, doc and
examples directories). The dependency on other NAnt build target should
be taken care of in the makefile.
why is that ? sure you'd want to install somthing thats built --
isn't that the point ? if you do a make install with most OSS projects
it will build first if its not up to date.
Yes, for source distributions that is But users cannot always build
a version of NAnt that is identical to what we want distribute, while
they still expect it to be ...
sure - again we are cross purposes -- Makefile is for building from
source, somthing else for a binary distribution.
For example :
Let's say we have an assembly that is Mono-specific. If we encourage
users to build NAnt from source, then users that don't have Mono
installed will not be able to build the Mono-specific assembly. However,
when they install Mono three later they would have been able to use the
Mono-specific tasks however these are not available (without rebuilding)
I'm not saying that we can't have users building from source, ofcourse
they can ... but we should not instruct them to do so
yes yes yes - I'm not saying we should instruct them to either -- hence
the seperate source and binary distributions. The buildfile/make file
should *not* be the installer for the binary only distribution.
Why should the dependency happen in the makefile ? Lets use NAnt for
this - its a build tool and it handle dependencies fine.
The reason why I wanted this is to allow the install targets to be used
from either the makefiles (to install either a freshly built NAnt or the
pre-built binaries) or the nightly build
Re: [nant-dev] Re: install targets
Gert Driesen wrote:
Ian,
After giving it some more thought, I think the "install" target of
the makefile should install the pre-built binaries and docs for
official NAnt distributions, not and rebuild the binaries from
source. We went to a lot of trouble in order to have a single binary
distribution, and I'd hate to see all that effort go to waste.
I disagree - this goes against how every other open source project
packages their distribution.
As I said before - its a source distribution that happens to include
pre built binaries *not* a binary distribution.
I actually consider it to be a binary distribution that happens to
include the source ;-)
thats the problem - right now we are a bit of both - thats what we need
to change.
I just don't understand why I went through all the trouble to allow us
to have a single binary distribution that can still take advantage of
framework-specific assemblies, if we instruct users to build a
framework specific version of NAnt.
we don't instruct them to do this -- that the point - we don't instruct
them to do anything but quite often they *do* build it because there is
a buildfile/make file and we never really provided proper installation
instructions.
Quite a while ago, we did agree that we should have a single binary
distribution that would work on all supported CLR's out-of-the-box,
right ? And now that we have it, we'd go back to having a
framework-specific binary install (with only very limited docs on
linux) ... not sure I understand the reason behind this ...
no - completely incorrect. The install target is *not* a substitute for
a binary installer. Its a convenience for when you build from source.
Its not meant to used as the installer for an end user.
What we should have (in my opinion) is :
- a source only distribution (containing only the binaries
necessary to build NAnt)
- a full binary distribution which would work on all supported
CLR's and platforms (this would be offered as a zip file or tar)
- an RPM release for linux
- an installer release for Windows
These last two would also install a full binary distribution ofcourse ...
I totally agree. I thought thats what I basically proposed.
Also, the install targets in the NAnt build file should no longer
depend on other build/doc targets (but they should just install
whatever files are available in ${build.dir} (limited to bin, doc
and examples directories). The dependency on other NAnt build target
should be taken care of in the makefile.
why is that ? sure you'd want to install somthing thats built --
isn't that the point ? if you do a make install with most OSS
projects it will build first if its not up to date.
Yes, for source distributions that is But users cannot always
build a version of NAnt that is identical to what we want distribute,
while they still expect it to be ...
sure - again we are cross purposes -- Makefile is for building from
source, somthing else for a binary distribution.
For example :
Let's say we have an assembly that is Mono-specific. If we encourage
users to build NAnt from source, then users that don't have Mono
installed will not be able to build the Mono-specific assembly.
However, when they install Mono three later they would have been able
to use the Mono-specific tasks however these are not available
(without rebuilding)
I'm not saying that we can't have users building from source, ofcourse
they can ... but we should not instruct them to do so
yes yes yes - I'm not saying we should instruct them to either -- hence
the seperate source and binary distributions. The buildfile/make file
should *not* be the installer for the binary only distribution.
Why should the dependency happen in the makefile ? Lets use NAnt for
this - its a build tool and it handle dependencies fine.
The reason why I wanted this is to allow the install targets to be
used from either the makefiles (to install either a freshly built NAnt
or the pre-built binaries) or the nightly build
once again - the makefile should not be the installer for pre-built
binaries IMHO.
my proposal - 2 download packages:
1) binaries only with a simple shell script to install on linux,
batch file for windows -- hopefully installer at some stage.
2) source package that mirrors the cvs tree. Use Make install to
build install on *nix, bin\NAnt.exe install to build install on windows.
This is a fairly standard packaging practice
It is because most oss project are not able to provide a single binary
distribution that works on all supported platforms ...
thats not true - its the standard for source based distributions - which
is what the install targets are for - a source based distro. The binary
distro should be seperate.
- getting clever with
multiple Makefiles seems like a recipe for confision.
What's difference between multiple makefiles (one for cvs/source
distribution and one for binary distribution), and one makefile and
on
Re: [nant-dev] Re: install targets
- Original Message -
From: "Ian MacLean" <[EMAIL PROTECTED]>
To: "Gert Driesen" <[EMAIL PROTECTED]>
Cc: "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]>
Sent: Friday, August 20, 2004 5:13 AM
Subject: [nant-dev] Re: install targets
Gert Driesen wrote:
Ian,
After giving it some more thought, I think the "install" target of the
makefile should install the pre-built binaries and docs for official NAnt
distributions, not and rebuild the binaries from source. We went to a lot
of trouble in order to have a single binary distribution, and I'd hate to
see all that effort go to waste.
I disagree - this goes against how every other open source project
packages their distribution.
As I said before - its a source distribution that happens to include pre
built binaries *not* a binary distribution.
I actually consider it to be a binary distribution that happens to include
the source ;-)
I just don't understand why I went through all the trouble to allow us to
have a single binary distribution that can still take advantage of
framework-specific assemblies, if we instruct users to build a framework
specific version of NAnt. Quite a while ago, we did agree that we should
have a single binary distribution that would work on all supported CLR's
out-of-the-box, right ? And now that we have it, we'd go back to having a
framework-specific binary install (with only very limited docs on linux) ...
not sure I understand the reason behind this ...
What we should have (in my opinion) is :
- a source only distribution (containing only the binaries necessary to
build NAnt)
- a full binary distribution which would work on all supported CLR's and
platforms (this would be offered as a zip file or tar)
- an RPM release for linux
- an installer release for Windows
These last two would also install a full binary distribution ofcourse ...
Also, the install targets in the NAnt build file should no longer depend
on other build/doc targets (but they should just install whatever files
are available in ${build.dir} (limited to bin, doc and examples
directories). The dependency on other NAnt build target should be taken
care of in the makefile.
why is that ? sure you'd want to install somthing thats built -- isn't
that the point ? if you do a make install with most OSS projects it will
build first if its not up to date.
Yes, for source distributions that is But users cannot always build a
version of NAnt that is identical to what we want distribute, while they
still expect it to be ...
For example :
Let's say we have an assembly that is Mono-specific. If we encourage users
to build NAnt from source, then users that don't have Mono installed will
not be able to build the Mono-specific assembly. However, when they install
Mono three later they would have been able to use the Mono-specific tasks
however these are not available (without rebuilding)
I'm not saying that we can't have users building from source, ofcourse they
can ... but we should not instruct them to do so
Why should the dependency happen in the makefile ? Lets use NAnt for
this - its a build tool and it handle dependencies fine.
The reason why I wanted this is to allow the install targets to be used from
either the makefiles (to install either a freshly built NAnt or the
pre-built binaries) or the nightly build
my proposal - 2 download packages:
1) binaries only with a simple shell script to install on linux, batch
file for windows -- hopefully installer at some stage.
2) source package that mirrors the cvs tree. Use Make install to build
install on *nix, bin\NAnt.exe install to build install on windows.
This is a fairly standard packaging practice
It is because most oss project are not able to provide a single binary
distribution that works on all supported platforms ...
- getting clever with
multiple Makefiles seems like a recipe for confision.
What's difference between multiple makefiles (one for cvs/source
distribution and one for binary distribution), and one makefile and one
shell script/batch file ? I don't see more or less confusion for any of
these ... It might even better to just be able to use "make install" for
both the source and the binary distributions ...
Regardless of that, users should actually use the binary release, not the
source release ... The binaries build from source will not match those that
are part of the binary release, this should be made very clear to the users
... The binaries built from source will not be able to run on all supported
frameworks, will not be able to run on all supported platform, will not
support all tasks ... and even the version number will not match that of the
binary release ...
Gert
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and F
