> * --enable-/--disable-directx should really force building with/without
> directx.
> default enabled is probably the best choice).
> * only if it's enabled, check for the dxsdk. using an environment
> variable instead of separate flag is fine, IMHO, as long as
> that variable is properly d
Hi,
> Anyway, about killing the --directx-home option, even if that is
> done,
> that does not mean having and building against the DirectX SDK (June
> 2010, or some earlier version) would be mandatory. It would just mean
> that if the standard DXSDK_DIR environment variable does not exist,
> then
BTW, as you no doubt will notice, we got a patch in from Peter Foley
through gerrit that does the kill-oowintool aspect of what I was
working on, great! That already cleans up things quite a bit.
Now just the reduce-unnecessary-options part is left to do, and
perhaps some tweaking of preference in
Le Wed, 05 Dec 2012 16:56:23 +0100, Norbert Thiebaud
a écrit:
On Wed, Dec 5, 2012 at 9:43 AM, Tor Lillqvist wrote:
to be able to reproduce a scenario: build using the same config than
the one that broke ?
Hmm, but there are tons of stuff that can break in various ways,
should we have opti
On Wed, Dec 5, 2012 at 9:43 AM, Tor Lillqvist wrote:
>> to be able to reproduce a scenario: build using the same config than
>> the one that broke ?
>
> Hmm, but there are tons of stuff that can break in various ways,
> should we have options permanently in there to intentionally reproduce
> all o
> to be able to reproduce a scenario: build using the same config than
> the one that broke ?
Hmm, but there are tons of stuff that can break in various ways,
should we have options permanently in there to intentionally reproduce
all of them?
--tml
___
On Wed, Dec 5, 2012 at 12:25 AM, Tor Lillqvist wrote:
> Anyway, about killing the --directx-home option, even if that is done,
> that does not mean having and building against the DirectX SDK (June
> 2010, or some earlier version) would be mandatory. It would just mean
> that if the standard DXSDK
Anyway, about killing the --directx-home option, even if that is done,
that does not mean having and building against the DirectX SDK (June
2010, or some earlier version) would be mandatory. It would just mean
that if the standard DXSDK_DIR environment variable does not exist,
then DirectX use is n
Hi,
On Tue, Dec 04, 2012 at 09:37:13PM +0100, David Ostrovsky wrote:
> No, you can't. One can only install DirectX SDK if windows is activated.
> So please don't break free tool chain on windows:
>
> * non activated windows
why would you not activate windows? For whatever "data protection" or be
> So please don't break free tool chain on windows:
>
> * non activated windows
How does not activating your Windows installation reduce the purchase
price of its license (if you mean "free as in beer", or make it less
proprietary (if you mean "free as in speech")? Or what are you saying
here?
Or
Am 04.12.2012 21:16, schrieb Mat M:
Le Tue, 04 Dec 2012 07:24:18 +0100, Tor Lillqvist a écrit:
--directx-home
Well, you can find it in registry, but there is no standard variable
that
points to it.
But oowintool manages to find it, so it can't be impossible? Or is
that just some versions
--directx-home
>>> Well, you can find it in registry, but there is no standard variable that
>>> points to it.
>> But oowintool manages to find it, s
> oowintool provides nothing to this regard currently
Ah you are right. But configure.ac by default takes it from the
environment, it claims
Good evening Tor, all
Le Tue, 04 Dec 2012 07:24:18 +0100, Tor Lillqvist a écrit:
Does anybody use VS Express 2010?
Me, me, me !!! :-)
OK, will have to test with that, too, then...
I could if you push a branch somewhere
--dotnet-framework-home
This one, because /lib/mscoree.lib is no
>> Does anybody use VS Express 2010?
> Me, me, me !!! :-)
OK, will have to test with that, too, then...
>> --dotnet-framework-home
> This one, because /lib/mscoree.lib is not where you expect it (In my case,
> in an SDK 6 subfolder)
OK, still that should be automateable, I hope.
>> --windows-
Le Mon, 03 Dec 2012 10:06:46 +0100, Tor Lillqvist a écrit:
Below is what have so far, not finished yet, still bugs in the
changes, and I probably want to get rid of the remaining uses of
oowintool, and then before committing I need to verify carefully that
it produces an equivalent config_host.
Below is what have so far, not finished yet, still bugs in the
changes, and I probably want to get rid of the remaining uses of
oowintool, and then before committing I need to verify carefully that
it produces an equivalent config_host.mk as the old one (and that it
builds, of course) for all three
Hello Tor,
Le Wed, 28 Nov 2012 20:23:09 +0100, Tor Lillqvist a écrit:
Our current set of configure options related to the MSVC build
tool-chain is quite messy and illogical. I think we should clean that
up.
Currently we have at least:
--with-cl-home
--with-mspdb-path
--with-midl-path
--with-
Our current set of configure options related to the MSVC build
tool-chain is quite messy and illogical. I think we should clean that
up.
Currently we have at least:
--with-cl-home
--with-mspdb-path
--with-midl-path
--with-csc-path
--with-dotnet-framework-home
--with-windows-sdk-home
--with-direct
18 matches
Mail list logo
