Menu
▾
▴
wxlua-users
|
From: Francesco M. <f18...@ya...> - 2006-01-23 22:30:31
|
Hi,
I've tried last wxLua (with my bakefile changes) on win32 with MSVC
.NET; almost everything went fine after setting the WXWIN env variable,
compiling wxWidgets and converting msvc6 projects to a .SLN file.
I say "almost" because I get errors about a wxWinHelpController not
defined and a "new wxDC()" which cannot be done because wxDC is abstract.
This could be because I'm using wxCVS (both on win32 and on linux).
Does anyone got my same problems ?
Francesco
|
|
From: klaas.holwerda <kho...@xs...> - 2006-01-24 23:00:54
|
Hi, Trying to test it. In the project file wxLua.dsw, VC6 could not find target app_wxLua, it seems to search for wxLua/apps/build/msw/apps.dsp. And indeed i could not find it, although there is apps.dsw. Can you fix that? Is there already a cleanall /deep ? I see that things get mixed up in project files, so a real good/all clean like in wxArt2D is needed i think. I think we need a install.html. At least for now batch build does not work yet, for all configurations (DLL). So i just do debug and release from selection in batch build. mod_wxbind tells me that luasetup.h can not be found? Others or oke. It is at e.g. print.cpp at #include "luasetup.h" regards, Klaas Francesco Montorsi wrote: > Hi, > I've tried last wxLua (with my bakefile changes) on win32 with > MSVC .NET; almost everything went fine after setting the WXWIN env > variable, compiling wxWidgets and converting msvc6 projects to a .SLN > file. > > I say "almost" because I get errors about a wxWinHelpController not > defined and a "new wxDC()" which cannot be done because wxDC is abstract. > > This could be because I'm using wxCVS (both on win32 and on linux). > > Does anyone got my same problems ? > > Francesco > |
|
From: klaas.holwerda <kho...@xs...> - 2006-01-24 23:11:41
|
and in the others i see wxluasetup.h ? Generated the bindings once more, and no it is luasetup.h all over?? I wonder what i did do wrong? So leafs the not found target. I see in the modules a split in sourse and headers, nice! Can it be made non capital in all cases? In apps.dsw, i get can not open wxmsw27d_xrc.lib, indeed that i don't have ;-) I have wxmsw26d_xrc.lib, how come? How does one deal with stedit in the second target? Maybe that should go into install.html too. Tomorrow i will test more. regards, Klaas klaas.holwerda wrote: > Hi, > > Trying to test it. > > In the project file wxLua.dsw, VC6 could not find target app_wxLua, it > seems to search for > wxLua/apps/build/msw/apps.dsp. > And indeed i could not find it, although there is apps.dsw. > > Can you fix that? > > Is there already a cleanall /deep ? I see that things get mixed up in > project files, so a real good/all clean like in wxArt2D is needed i > think. > > I think we need a install.html. > At least for now batch build does not work yet, for all configurations > (DLL). > So i just do debug and release from selection in batch build. > > mod_wxbind tells me that luasetup.h can not be found? Others or oke. > > It is at e.g. print.cpp at #include "luasetup.h" > > regards, > > Klaas > > Francesco Montorsi wrote: > >> Hi, >> I've tried last wxLua (with my bakefile changes) on win32 with >> MSVC .NET; almost everything went fine after setting the WXWIN env >> variable, compiling wxWidgets and converting msvc6 projects to a .SLN >> file. >> >> I say "almost" because I get errors about a wxWinHelpController not >> defined and a "new wxDC()" which cannot be done because wxDC is >> abstract. >> >> This could be because I'm using wxCVS (both on win32 and on linux). >> >> Does anyone got my same problems ? >> >> Francesco >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Wxlua-users mailing list > Wxl...@li... > https://lists.sourceforge.net/lists/listinfo/wxlua-users > > |
|
From: John L. <jla...@gm...> - 2006-01-25 04:50:02
|
On 1/24/06, klaas.holwerda <kho...@xs...> wrote: > and in the others i see wxluasetup.h ? > > Generated the bindings once more, and no it is luasetup.h all over?? > I wonder what i did do wrong? It's called wxluasetup.h now. > So leafs the not found target. > > I see in the modules a split in sourse and headers, nice! > Can it be made non capital in all cases? > > In apps.dsw, i get can not open wxmsw27d_xrc.lib, indeed that i don't > have ;-) > I have wxmsw26d_xrc.lib, how come? The last update using bakefile has changed from 26 to 27. I use wxWidgets CVS head so this is not a problem, but we should revert to 26 since that is the stable brach of wxWidgets. > How does one deal with stedit in the second target? Maybe that should go > into install.html too. What second target? > > Trying to test it. > > > > In the project file wxLua.dsw, VC6 could not find target app_wxLua, it > > seems to search for > > wxLua/apps/build/msw/apps.dsp. > > And indeed i could not find it, although there is apps.dsw. > > > > Can you fix that? apps.dsp has been removed, do another checkout. > > Is there already a cleanall /deep ? I see that things get mixed up in > > project files, so a real good/all clean like in wxArt2D is needed i > > think. A clean checkout is probably best. -John |
|
From: k. h. <kla...@nl...> - 2006-01-25 09:05:23
|
Hi, John Labenski wrote: >>So leafs the not found target. >> >>I see in the modules a split in sourse and headers, nice! >>Can it be made non capital in all cases? >> >>In apps.dsw, i get can not open wxmsw27d_xrc.lib, indeed that i don't >>have ;-) >>I have wxmsw26d_xrc.lib, how come? >> >> > >The last update using bakefile has changed from 26 to 27. I use >wxWidgets CVS head so this is not a problem, but we should revert to >26 since that is the stable brach of wxWidgets. > > I am suprized why it is not recognized automatically using WXWIN? All other are oke. Anyway i changed it to 26 and after correcting all other problems, i did get an error in lua. (wxStyledTextCtrl (a nil value ). > > >>How does one deal with stedit in the second target? Maybe that should go >>into install.html too. >> >> > >What second target? > > wxluaedit uses stedit, so the second target in that apps.dsw > > >>>Trying to test it. >>> >>>In the project file wxLua.dsw, VC6 could not find target app_wxLua, it >>>seems to search for >>>wxLua/apps/build/msw/apps.dsp. >>>And indeed i could not find it, although there is apps.dsw. >>> >>>Can you fix that? >>> >>> > >apps.dsp has been removed, do another checkout. > > I know that, but it is still referred to from wxLua.dsw. I just did another checkout, wxLua.dsw contains this line ( see apps.dsp ), which can not be found. Project: "app_wxlua"=..\..\apps\build\msw\apps.dsp - Package Owner=<4> And it is all LF again, so no project file works anymore. Converting by hand back to CRLF makes apps.dsp the problem again. Project: "apps_app_wxlua"=..\..\apps\build\msw\apps_app_wxlua.dsp - Package Owner=<4> Project: "apps_app_wxluaedit"=..\..\apps\build\msw\apps_app_wxluaedit1.dsp - Package Owner=<4> > > >>>Is there already a cleanall /deep ? I see that things get mixed up in >>>project files, so a real good/all clean like in wxArt2D is needed i >>>think. >>> >>> > >A clean checkout is probably best. > > No bettter copy that bakefile part from wxArt2D, it should be the same. Then using the makefiles one can do a proper clean. Klaas Unclassified |
|
From: Francesco M. <f18...@ya...> - 2006-01-25 18:27:24
|
Hi, k. holwerda ha scritto: > Hi, > > John Labenski wrote: > >>> So leafs the not found target. >>> >>> I see in the modules a split in sourse and headers, nice! >>> Can it be made non capital in all cases? >>> >>> In apps.dsw, i get can not open wxmsw27d_xrc.lib, indeed that i don't >>> have ;-) >>> I have wxmsw26d_xrc.lib, how come? >>> >> >> >> The last update using bakefile has changed from 26 to 27. I use >> wxWidgets CVS head so this is not a problem, but we should revert to >> 26 since that is the stable brach of wxWidgets. sure; that's my fault. I'm going to set it in wxLua bakefiles so that won't be a problem anymore. >> >> > I am suprized why it is not recognized automatically using WXWIN? WXWIN only gives info about location of wxWidgets, not its version. >>> How does one deal with stedit in the second target? Maybe that should go >>> into install.html too. >>> >> >> >> What second target? >> >> > wxluaedit uses stedit, so the second target in that apps.dsw if I understand it correctly (please remember that it's quite a bit of time I'm not using MSVC anymore and I don't have a fresh idea of how wxLua project files look and how many are the targets and how they are exactly named :)), this is the same problem I have on linux :) See problem #1 in my "Remaining problems" mails >>>> Trying to test it. >>>> >>>> In the project file wxLua.dsw, VC6 could not find target app_wxLua, it >>>> seems to search for >>>> wxLua/apps/build/msw/apps.dsp. >>>> And indeed i could not find it, although there is apps.dsw. >>>> >>>> Can you fix that? >>>> >> >> >> apps.dsp has been removed, do another checkout. anyway I updated apps.dsw to match the new DSP names > And it is all LF again, so no project file works anymore. if you are checking out from a win32 box and DSP files were added to CVS repository as text files, this should never happen (CVS should check them out using CRLF). Maybe they were added as binary. In frm-bakefile 0.2.0 I have added a --crlf=(native|dos|mac|unix) option which I could use to tell bakefile_gen to generate DSW/DSP files always with dos EOL... I'm going to do that ASAP. >>>> Is there already a cleanall /deep ? I see that things get mixed up in >>>> project files, so a real good/all clean like in wxArt2D is needed i >>>> think. I'll test wxLua project files as soon as linux problems are solved... Francesco |
|
From: Francesco M. <f18...@ya...> - 2006-01-25 19:18:05
|
Hi,
just committed the following build fixes:
-> wx default version is now 2.6
-> DSW/DSP files use CRLF EOL
-> wxLua's configure can be called from any directory
(running wxLua/mybuild/../configure && make && make install now works)
-> fixed wxLua.dsw
Francesco
Francesco Montorsi ha scritto:
> Hi,
>
> k. holwerda ha scritto:
>
>> Hi,
>>
>> John Labenski wrote:
>>
>>>> So leafs the not found target.
>>>>
>>>> I see in the modules a split in sourse and headers, nice!
>>>> Can it be made non capital in all cases?
>>>>
>>>> In apps.dsw, i get can not open wxmsw27d_xrc.lib, indeed that i don't
>>>> have ;-)
>>>> I have wxmsw26d_xrc.lib, how come?
>>>>
>>>
>>>
>>>
>>> The last update using bakefile has changed from 26 to 27. I use
>>> wxWidgets CVS head so this is not a problem, but we should revert to
>>> 26 since that is the stable brach of wxWidgets.
>
> sure; that's my fault.
> I'm going to set it in wxLua bakefiles so that won't be a problem anymore.
>
>
>>>
>>>
>> I am suprized why it is not recognized automatically using WXWIN?
>
> WXWIN only gives info about location of wxWidgets, not its version.
>
>
>>>> How does one deal with stedit in the second target? Maybe that
>>>> should go
>>>> into install.html too.
>>>>
>>>
>>>
>>>
>>> What second target?
>>>
>>>
>> wxluaedit uses stedit, so the second target in that apps.dsw
>
> if I understand it correctly (please remember that it's quite a bit of
> time I'm not using MSVC anymore and I don't have a fresh idea of how
> wxLua project files look and how many are the targets and how they are
> exactly named :)), this is the same problem I have on linux :)
>
> See problem #1 in my "Remaining problems" mails
>
>
>>>>> Trying to test it.
>>>>>
>>>>> In the project file wxLua.dsw, VC6 could not find target app_wxLua, it
>>>>> seems to search for
>>>>> wxLua/apps/build/msw/apps.dsp.
>>>>> And indeed i could not find it, although there is apps.dsw.
>>>>>
>>>>> Can you fix that?
>>>>>
>>>
>>>
>>>
>>> apps.dsp has been removed, do another checkout.
>
> anyway I updated apps.dsw to match the new DSP names
>
>
>> And it is all LF again, so no project file works anymore.
>
> if you are checking out from a win32 box and DSP files were added to CVS
> repository as text files, this should never happen (CVS should check
> them out using CRLF). Maybe they were added as binary.
> In frm-bakefile 0.2.0 I have added a --crlf=(native|dos|mac|unix) option
> which I could use to tell bakefile_gen to generate DSW/DSP files always
> with dos EOL...
>
> I'm going to do that ASAP.
>
>
>>>>> Is there already a cleanall /deep ? I see that things get mixed up in
>>>>> project files, so a real good/all clean like in wxArt2D is needed i
>>>>> think.
>
> I'll test wxLua project files as soon as linux problems are solved...
>
> Francesco
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
|
|
From: k. h. <kla...@nl...> - 2006-01-26 08:37:53
|
Francesco Montorsi wrote: > -> wxLua's configure can be called from any directory > (running wxLua/mybuild/../configure && make && make install now works) So you mean building outside wxLua too, and all stuff going there? That is really cool! > -> fixed wxLua.dsw Oke thanks, Will test now. Klaas -- Unclassified |
|
From: k. h. <kla...@nl...> - 2006-01-26 09:30:00
|
k. holwerda wrote: > > > Francesco Montorsi wrote: > > >> -> fixed wxLua.dsw > app_wxlua complains in batch build that it can not find wxluasocket.lib, but the second time it is oke, I think this is a dependency problem. --------------------Configuration: app_wxlua - Win32 Debug-------------------- Compiling resources... Compiling... lconsole.cpp wxlua.cpp Generating Code... Linking... LINK : fatal error LNK1104: cannot open file "wxluasocket.lib" Error executing link.exe. Can the default configuration be set to debug? Or is this not best? After setting WXSTEDIT correctly, i still get, and doing: // If you get an error on this line, maybe you forgot to copy // include/wx/stedit/setup0.h to include/wx/stedit/setup.h ? I get this: --------------------Configuration: app_wxluaedit - Win32 Debug-------------------- Linking... LINK : fatal error LNK1104: cannot open file "wxmsw26d_stedit.lib" Error executing link.exe. wxluaedit.exe - 1 error(s), 0 warning(s) BTW what did i see when compiling wxstedit, yecka there it is again ;-) --------------------Configuration: wxstedit - Win32 Debug-------------------- Compiling resources... Compiling... wxstedit.cpp Linking... LINK : warning LNK4098: defaultlib "MSVCRT" conflicts with use of other libs; use /NODEFAULTLIB:library wxstedit.exe - 0 error(s), 1 warning(s) My stedit produces libraries steditd.lib and stedit.lib, do i need an update there? Anyway i renamed them, but same problem, I think ( i am sure ) you need to add: /libpath:"$(WXSTEDIT)\lib" Oke running app_wxluaedit gives me ( this must be because of the swicth problem again ): NTDLL! 77f767cd() NTDLL! 77f6a6a0() KERNEL32! 77e6c7c4() _CrtIsValidHeapPointer(const void * 0x01222d08) line 1697 _free_dbg_lk(void * 0x01222d08, int 1) line 1044 + 9 bytes _free_dbg(void * 0x01222d08, int 1) line 1001 + 13 bytes free(void * 0x01222d08) line 956 + 11 bytes wxListKey::~wxListKey() line 379 + 15 bytes wxListBase::Append(const char * 0x00b5089c, void * 0x00c47760 class wxClassInfo wxLuaShell::ms_classInfo) line 273 wxObjectList::Append(const char * 0x00b5089c, void * 0x00c47760 class wxClassInfo wxLuaShell::ms_classInfo) line 1122 + 30 bytes wxHashTable::Put(const char * 0x00b5089c, wxObject * 0x00c47760 class wxClassInfo wxLuaShell::ms_classInfo) line 485 wxClassInfo::Register() line 245 wxClassInfo::wxClassInfo(const char * 0x00b5089c, const wxClassInfo * 0x00c483c0 class wxClassInfo wxSTEditorShell::ms_classInfo, const wxClassInfo * 0x00000000, int 472, wxObject * (void)* 0x00000000) line 77 $E391() line 48 + 32 bytes $E395() + 8 bytes _initterm(void (void)* * 0x00b4d10c $S396, void (void)* * 0x00b4e8a8 ___xc_z) line 525 WinMainCRTStartup() line 274 + 15 bytes KERNEL32! 77e8141a() It looks like the problem is in wxstedit all the time ( which i am using in wxArt2D too ). Hope you can fix this. app_wxlua complains about wxStryledTextCtrl being nill, which is a lua problem i think. Coming closer to perfect ;-) regards, Klaas -- Unclassified |
|
From: John L. <jla...@gm...> - 2006-01-27 23:00:26
|
On 1/26/06, k. holwerda <kla...@nl...> wrote:
> After setting WXSTEDIT correctly, i still get, and doing:
>
> // If you get an error on this line, maybe you forgot to copy
> // include/wx/stedit/setup0.h to include/wx/stedit/setup.h ?
You have to copy this by hand, this is intentional.
> I get this:
>
> --------------------Configuration: app_wxluaedit - Win32
> Debug--------------------
> Linking...
> LINK : fatal error LNK1104: cannot open file "wxmsw26d_stedit.lib"
> Error executing link.exe.
>
> wxluaedit.exe - 1 error(s), 0 warning(s)
>
> BTW what did i see when compiling wxstedit, yecka there it is again ;-)
>
> --------------------Configuration: wxstedit - Win32
> Debug--------------------
> Compiling resources...
> Compiling...
> wxstedit.cpp
> Linking...
> LINK : warning LNK4098: defaultlib "MSVCRT" conflicts with use of other
> libs; use /NODEFAULTLIB:library
>
> wxstedit.exe - 0 error(s), 1 warning(s)
>
>
> My stedit produces libraries steditd.lib and stedit.lib, do i need an
> update there?
> Anyway i renamed them, but same problem,
>
> I think ( i am sure ) you need to add:
>
> /libpath:"$(WXSTEDIT)\lib"
>
>
> Oke running app_wxluaedit gives me ( this must be because of the swicth
> problem again ):
>
> NTDLL! 77f767cd()
> NTDLL! 77f6a6a0()
> KERNEL32! 77e6c7c4()
> _CrtIsValidHeapPointer(const void * 0x01222d08) line 1697
> _free_dbg_lk(void * 0x01222d08, int 1) line 1044 + 9 bytes
> _free_dbg(void * 0x01222d08, int 1) line 1001 + 13 bytes
> free(void * 0x01222d08) line 956 + 11 bytes
> wxListKey::~wxListKey() line 379 + 15 bytes
> wxListBase::Append(const char * 0x00b5089c, void * 0x00c47760 class
> wxClassInfo wxLuaShell::ms_classInfo) line 273
> wxObjectList::Append(const char * 0x00b5089c, void * 0x00c47760 class
> wxClassInfo wxLuaShell::ms_classInfo) line 1122 + 30 bytes
> wxHashTable::Put(const char * 0x00b5089c, wxObject * 0x00c47760 class
> wxClassInfo wxLuaShell::ms_classInfo) line 485
> wxClassInfo::Register() line 245
> wxClassInfo::wxClassInfo(const char * 0x00b5089c, const wxClassInfo *
> 0x00c483c0 class wxClassInfo wxSTEditorShell::ms_classInfo, const
> wxClassInfo * 0x00000000, int 472, wxObject * (void)* 0x00000000) line 77
> $E391() line 48 + 32 bytes
> $E395() + 8 bytes
> _initterm(void (void)* * 0x00b4d10c $S396, void (void)* * 0x00b4e8a8
> ___xc_z) line 525
> WinMainCRTStartup() line 274 + 15 bytes
> KERNEL32! 77e8141a()
>
>
> It looks like the problem is in wxstedit all the time ( which i am using
> in wxArt2D too ).
>
> Hope you can fix this.
>
> app_wxlua complains about wxStryledTextCtrl being nill, which is a lua
> problem i think.
Somehow linking to the wxStyledTextCtrl has been removed from the dsp
files and that wxLUA_USE_wxStyledTextCtrl has been set to 0 in
wxluasetup.h. By default these two MUST be on for the main wxLua app
to run. You can turn them off in your version. This is why it so
important that it's easy create different wxbind lib versions, one for
the wxLua app and one for your own programs. I will try my hand with
the new bakefile to link to stc again.
Regards,
John Labenski
|
|
From: Francesco M. <f18...@ya...> - 2006-01-27 23:13:45
|
Hi, John Labenski ha scritto: >>app_wxlua complains about wxStryledTextCtrl being nill, which is a lua >>problem i think. > > > Somehow linking to the wxStyledTextCtrl has been removed from the dsp > files and that wxLUA_USE_wxStyledTextCtrl has been set to 0 in > wxluasetup.h. Sorry; probably it was my fault. I probably committed my local wxluasetup.h changes together with new makefiles. >By default these two MUST be on for the main wxLua app > to run. I think that wxLua should build out of the box against a properly installed wxWidgets. However contribs are not installed by default. Nor there is a wxUSE_STC symbol anywhere in STC contrib which we can use to detect STC. I think that: 1) we should make wxStyledTextCtrl optional, maybe replacing it with a less powerful editor... 2) add a check in configure script for its presence; if present configure should set the wxLUA_USE_wxStyledTextCtrl to 1 otherwise to 0. This can be done only using wxluasetup.h.in -> wxluasetup.h. I did try to move bindings/wxwidgets/wxluasetup.h.in to modules/wxbind/include but I've found that there is a CPP file (linternal.cpp IIRC) that uses wxluasetup.h.in directly. Why ? More generally this problem (listed as #1 in my "Remaining problems" mail) can be solved only using configure checks at run-time, IMO. This is because while all other features presence can be auto-recognized using wxUSE_* symbols, contrib libs and 3rd party code cannot. What do you think ? > You can turn them off in your version. This is why it so > important that it's easy create different wxbind lib versions, one for > the wxLua app and one for your own programs. I will try my hand with > the new bakefile to link to stc again. so the WXLUASETUP_DIR and WXLUABINDLIB_DIR options (point #7) must be made operational, right ? I'll try this tomorrow... Good night :) Francesco |
|
From: klaas.holwerda <kho...@xs...> - 2006-01-28 13:04:41
|
Francesco Montorsi wrote: > > More generally this problem (listed as #1 in my "Remaining problems" > mail) can be solved only using configure checks at run-time, IMO. > This is because while all other features presence can be > auto-recognized using wxUSE_* symbols, contrib libs and 3rd party code > cannot. > What do you think ? Why not just put it in install.html. wxWidgets its contrib organization is no good, that is the problem. If one compromizes because others are unable to organize the stuff, that is a bit weird. If this is really such an issue, there is always a thirdparty libs trick, meaning copy it in CVS and use it, if not available somewhere else. There is also wxstedit which is needed. Just stop configure if certain things are not available/installed, and tell what is needed. Klaas |
|
From: Francesco M. <f18...@ya...> - 2006-01-28 14:05:41
|
Hi,
klaas.holwerda ha scritto:
> Francesco Montorsi wrote:
>> More generally this problem (listed as #1 in my "Remaining problems"
>> mail) can be solved only using configure checks at run-time, IMO.
>> This is because while all other features presence can be
>> auto-recognized using wxUSE_* symbols, contrib libs and 3rd party code
>> cannot.
>> What do you think ?
>
>
> Why not just put it in install.html. wxWidgets its contrib organization
> is no good, that is the problem.
> If one compromizes because others are unable to organize the stuff, that
> is a bit weird.
you are referring to my proposal of making wxStyledTextCtrl as optional,
right ?
well, I think it would be a nice thing but I do agree that's not
strictly required once we document in install.html that one needs to:
-> on win32, open contrib/build/stc/stc.dsw and build it
(or do the same with makefiles)
-> on linux, go to contrib/src/stc and use
make install
Still, it would be nice to have a fallback.
And surely we need to check for it in configure script, at least on Unix.
> If this is really such an issue, there is always a thirdparty libs
> trick, meaning copy it in CVS and use it, if not available somewhere else.
that could be a choice.
John, what do you propose ?
> There is also wxstedit which is needed.
I didn't know that.
It's from wxCode. I'm trying to build it; I'll let you know.
Anyway on Unix it would be easy to check for its presence using the
AM_WXCODE_CHECKFOR_COMPONENT I created in wxcode.m4 macro file.
> Just stop configure if certain things are not available/installed, and
> tell what is needed.
I prefer those configure which instead of stopping warn you that the
feature X is not available and provide a fallback for it :)
Francesco
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X