NAnt. I'm also wondering why you think this is important or useful.
It's useful in the GNU configure/auto-conf, because there are many
packages generated that way, so that the configuration files can be
provided with the kit and installed into the pkg-config lib directory.
I don't know that there are many Visual C++ users who will be building
against such packages, but if there are, you need to use the config
files that come with them, i.e. pkg-config syntax, not property files.
On the other hand, if you're thinking about packages that are intended
for VC++ development, I'd expect Visual Studio project and/or solution
files to be the approach.
The task I'm working on should compile using both visual c++, and gcc,
wihtout having to change the xml format, so that programs that are created
on unix should compile without problems on windows (I believe this was one
of the main reasons the original ant author created ant). If you want to
be able to use packages on unix, and also be able to compile it on
windows, you somehow need a way to associate the librariy files with a
package name.
I think property sheets are a great way to do this. Right now I already
have property sheets for most third pary stuff I use, so that I don't have
to reconfigure all library dependencies and other settings each time I
start a new project. I also think it would be handy if these property
sheets would already be included in the distribution of those libraries,
so configuring becomes a matter of adding one property sheet to your
project. Since property sheets are a great way to configure libraries, I
think it would be a good idea to use them, instead of inventing a new
format.
You will probably have to copy the property sheets of 3rd party libraries
to some directory by hand, to be able to use it from that
win-pkg-congfige, but that's way easier than having to open visual studio,
and changing your include and library paths for each library you
installed. And if it goes well, some packages may automatically install it
in the right folder( or just place a shortcut)
Anyway, I think I'll go for the seperate tool.
Greets,
Lieven van der Heide.
On Fri, 26 May 2006 18:40:13 +0200, Gary Feldman
<[EMAIL PROTECTED]> wrote:
LievenQ wrote:
The problem is that visual studio doesn't have a system like
pkg-config. To solve this, I was thinking about creating a pkg-config
like system for visual studio myself. The package files would be simple
visual c++ 2005 proprety sheets, so that they are fully supported with
visual studio by itself. These property sheets should be placed in a
folder, and my task will then look up packages in that folder, and use
the appropriate property sheets.
How are you planning on generating the property sheets? With
pkg-config, they're usually generated by the configure utility or
similar.
Now I'm not sure in which folder I should place these property sheets
though. I could create a subfolder in the nant directory, but I don't
think that would be a good idea, because those files aren't really part
of nant itself. I could also create a folder in the root, but that
wouldn't be too polite to the user's system. Program Files maybe?
Anybody got another suggestion?
I think you hinted on the right direction above, when you said you were
thinking about creating a pkg-config like system. That means you should
be thinking in terms of win-pkg-config (to coin a name), instead of
NAnt. I'm also wondering why you think this is important or useful.
It's useful in the GNU configure/auto-conf, because there are many
packages generated that way, so that the configuration files can be
provided with the kit and installed into the pkg-config lib directory.
I don't know that there are many Visual C++ users who will be building
against such packages, but if there are, you need to use the config
files that come with them, i.e. pkg-config syntax, not property files.
On the other hand, if you're thinking about packages that are intended
for VC++ development, I'd expect Visual Studio project and/or solution
files to be the approach.
Gary
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications
in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers
