User forums > Nightly builds

The 13 August 2022 build (12864) is out.

<< < (5/15) > >>

AndrewCot:
gd_on,
Thanks for taking the time to check out my project file changes and taking the time to make them better as per below.

Is it possible to get a 7z file with the directory structure preserved as then the project files will land in the correct directory if you unzip it in the correct directory. If you have a repo some where with the code I can grab the files from there to save time.

Is is also possible to get a copy of the config snippet for the global variables needed?
From my quick 5 minute look it seems that the $(CB_BUILD) has not been included. If this is the only change then it will help out a heck of allot and ensure that only one set of project files are
needed. The lack of using $(CB_BUILD) is a good one as it does bite when you move code and I have no problems with it's removal as it will lessen issues devs face (btw I keep getting issues with when I make copies of the soruce tree and forget to update it, so I am starting to <expletive removed> with it and have been thinking of reverting it for the last month). I will be incorporating the removal of the $(CB_BUILD) as I think it is the correct way to go.

ollydbg:

--- Quote from: AndrewCot on August 17, 2022, 12:34:03 am ---
Is is also possible to get a copy of the config snippet for the global variables needed?
From my quick 5 minute look it seems that the $(CB_BUILD) has not been included. If this is the only change then it will help out a heck of allot and ensure that only one set of project files are
needed. The lack of using $(CB_BUILD) is a good one as it does bite when you move code and I have no problems with it's removal as it will lessen issues devs face (btw I keep getting issues with when I make copies of the soruce tree and forget to update it, so I am starting to <expletive removed> with it and have been thinking of reverting it for the last month). I will be incorporating the removal of the $(CB_BUILD) as I think it is the correct way to go.

--- End quote ---

I just looked at the Cbps.7z file supplied by gd_on, it has some code snippet like:


--- Code: --- <Target title="scintilla">
<Option output="devel$(#WXWIDGETS.WX_VERSION)_$(#CB_BUILD.OSBITS)/wxscintilla_cb" prefix_auto="1" extension_auto="1" />
<Option working_dir="" />
<Option object_output=".objs$(#WXWIDGETS.WX_VERSION)_$(#CB_BUILD.OSBITS)" />

--- End code ---

So, I'm not sure how can you do that if you remove the "$(CB_BUILD)" (global variable) and use the existing "cb_release_type" variable?

gd_on:
Here is an other packaging of my cbps for windows. I have also added in a pdf how env_vars are configured for me.
Nevetheless, my cbps still use some update*.bat which are not wxwidgets version independant. May be need still some work...

MortenMacFly:

--- Quote from: killerbot on August 16, 2022, 08:36:05 pm ---why do we even still but the effort in 32 bits, is there still some operating system supported by the vendors in 32 bit ?

--- End quote ---
From my point of view: Yes.

Reasons are:
1.) 32 bit IDE for 32 Bit compilers which are very well common in embedded environment (where you have the issue that a 32 bit gdb will not work in a 64 bit runtime)
2.) Schools and universities (which are main users of C::B) are still on 32 bit quite often
3.) We were nagged several times after we tried to released 64 bit only. We can try again, but I guess we will again be asked accordingly

MortenMacFly:

--- Quote from: gd_on on August 17, 2022, 10:58:06 am ---Nevetheless, my cbps still use some update*.bat which are not wxwidgets version independant. May be need still some work...

--- End quote ---
I once played around with that and made the batch file accept a command line parameter that defines the wx version. This used to work. (I.e. when calling the batch file just call it with the value of the #wx global var.)

Navigation

[0] Message Index

[#] Next page

[*] Previous page