Maybe we could give it a better name? I'd like to see something that
reflects the fact that it is setting properties, like maybe
.
Eric.
> -Original Message-
> From: Griffin Caprio [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 13, 2003 10:48 AM
> To: Arjen Poutsma; Nant-Developers (
> This is a little different than other approaches we've had
> before, but here's one approach I think could work: Don't
> make it an actual property! Instead, make it an actual
> command line switch, like:
>
> nant.Console.exe -force build
> Then, have that set a real Property of the Proje
I like both of them. However, I have some issues with the "force"
attribute.
I would think the purpose of "force" would be to ensure that for a
one-time build everything got built. That is, it wouldn't normally be
used. I might use it if I thought that my objects were out of date, or
if somethi
Wouldn't something like make's ?= be useful here? The value is only
assigned if it doesn't already have a value. That way you could tell by
looking at the build file which variables were intended to be overriden
on the command line. In nant's case, maybe an extra attribute on the
property elemen
I've never been a fan of having everything recompile if the build file
(or makefile) changes. I often make changes to the build file that
don't invalidate any of the outputs. If anything, this should be
optional, but I'd rather see it not included. What does everyone else
think?
-Original
Title: Message
I
think it would cause problems. I never want to specify settings in the
environment. I want everything to be in the .build file. With this
patch, the environment would be silently used, without my
knowledge.
I
think you're better off having a task that sets a property f
> -Original Message-
> From: Jorge Bermejo [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 06, 2002 6:12 PM
> To: 'Shaw, Gerry'; '[EMAIL PROTECTED]'
> Subject: RE: [nant-dev] Modified LoopTask...
>
>
> Gerry-
> That's precisely the point, I "Do" want users to override (or
> trash)
> So people send in your votes on these topics:
> 1. or
propertygroup
> 2. separator attribute or no separator attribute
no separator
---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE
Title: Message
Space
delimited strings causes problems with paths with spaces in them, of
course. Unless you quote the filenames, but then you've got problems with
escaping the quote characters, etc.
I like
the id/ref idea. I suppose if you really liked the string approach, you
could se
> -Original Message-
> From: Kevin Dente [mailto:[EMAIL PROTECTED]]
>
> That's definitely not the case at my company. We have
> dozens of old-style DLLs with import libraries, and we
> use a library search path for those as well as system libraries.
Then in the proposed scheme you'd hav
I think the point is that the Microsoft libraries change so rarely that
it's not worth finding them, if that's all that you have on the library
search path. Just ignore them and only use your own libraries when
doing the dependency analysis.
Eric.
> -Original Message-
> From: Kevin Dent
> -Original Message-
> From: Tomas Restrepo [mailto:[EMAIL PROTECTED]]
>
> Well, the easy way out would be to distinguish between those
> libs that usually don't change (such as those provided by MS
> in VS or PSDK), and those you create in your projects which
> might change often. So
I agree with Tomas here. I run multiple versions and never have Nant or
similar tools in my path.
The environment variable is just one more thing to get wrong. A
pre-defined property could never be incorrect. Having to set
environment variables before a build will succeed has always seemed lik
I agree with Ian. It doesn't seem that local tasks would be a common
pattern, and it may well be confusing. I'd be more likely to do set up
tasks per machine and then leave it at that. His later point about
xchemas is also well made.
I think this should be buried in Scott's proposed config fil
t: Re: [nant-dev] Version task
>
>
> Smith, Eric V. wrote:
>
> > It's beginning to sound like my VersionTask isn't what people are
> > after
>
> It's what I want, and planned on writing. :)
>
> Brad
>
> --
> Read my web log at http:
How is that different from just having .cs file (say,
AssemblyVersion.cs) that only contains the version attribute? It's one
file instead of your two.
It's beginning to sound like my VersionTask isn't what people are after,
so I'll just keep it to myself and not put it in the Nant source.
Thanks
Page 61, inside the box.
> -Original Message-
> From: Andy Smith [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 22, 2002 4:56 PM
> To: Smith, Eric V.; [EMAIL PROTECTED]
> Subject: RE: [nant-dev] Version task
>
>
> I have that book, but don't remember re
ncrement the version. does this behavior only exist in c#???
>
>
> Andy Smith
> Chief Code Monkey
>
> -Original Message-
> From: Smith, Eric V. [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 22, 2002 2:07 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [n
t; Sent: Monday, April 22, 2002 3:34 PM
> To: Smith, Eric V.; [EMAIL PROTECTED]
> Subject: RE: [nant-dev] Version task
>
>
> Yeah, I think making the filename required is good. Or
> require a language attribute (it could be an enum). Then you
> could set the default filename ba
I
sort of like making it mandatory, so that you can look at the .build
file and tell where it's getting the version info.
Eric.
> -Original Message-
> From: Scott Hernandez [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 22, 2002 10:56 AM
> To: Smith, Eric V.
> Cc: [EM
I have created a task (VersionTask) that reads the AssemblyVersion
attribute from the AssemblyInfo.cs file. It handles all of the valid
version number formats:
1
1.2
1.2.*
1.2.3
1.2.3.*
1.2.3.4
It can set a nant property (Project.Properties) to any prefix of this
version number, that is it can s
I agree, this sounds like it wouldn't be a task. It sounds like it
should run after the tasks are loaded but before (and instead of) a
.build file is loaded.
> -Original Message-
> From: Scott Hernandez [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 15, 2002 7:43 PM
> To: 'Gerry Shaw'
I like the idea that the "static" properties are no different than any
other properties. I was going to add the path name of cl.exe as a
property to the cl task, but then thought better of it. With this
scheme I just make everything a property that can be set in any of the
config files.
However
I'm not exactly sure what you're driving at with the aliases. What
refers to the alias name attribute? Is it something in the .build file?
I don't like the config file being referred to in the .build file,
precisely because I want to store platform specific settings in the
config file. I don't
#x27;d be willing to work on this if the consensus is that it makes sense.
Eric.
> -Original Message-
> From: Kevin Dente [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 12, 2002 8:35 PM
> To: Smith, Eric V.; [EMAIL PROTECTED]
> Subject: RE: [nant-dev] RE: FileSet quest
Odd that you mention config files. I was just thinking about this
today.
What about having attributes on a task that are tied to a app.config
file and automatically set? For the cl, lib, etc. tasks, I need to know
the path to the compilers and linkers. Sure, it's probably in the PATH
(and that
26 matches
Mail list logo
