On Tue, Jan 19, 2016 at 1:56 PM, Jason Kenny <[email protected]> wrote:
> I think this is a great idea. > > > > However a word of warning. How this applied could break existing code > people have. > > > > Changing the env[“PLATFORM”] from posix to something like “linux” or > “Linux_debian” is not backward compatible. > > > > The reality is that a string was used for good or bad. > Strings as keys are bad most of the time; call me old fashioned, but I like strongly compiled languages which includes the ability to run pycompile and have it mean something (even if it's only a small something). > > > I would suggest that we defined something new so we don’t break existing > build code. I know I have suggested something from parts, but I seem to > have to make it a 100% independent package on pypi for it to be used by > SCons. > > > > I think we need to look at Greg’s Noel IAPAT idea. I been calling it > settings and have a great start of it going on Parts. I don’t think we want > do this kind of change without some thought. > > > > I personally think we should deprecate PLATFORM and replace it with a > HOST_XXX and TARGET_XXX value. Where XXX would be values like: > > > > 1) OS ( this is abstract) > > 2) OS-VARIANT/ Vender ( this is detailed) > > 3) Architecture ( this is abstract) > > 4) CPU-Type( this is detailed) > I am alight with this; I like enumerations, but I do not like using enumerations directly unless they are NEVER related (IE. always disjoint concepts). I think you are implying that an API should exist for this; you explain more below. I find that enumerations are generally related, so you get Set Theory applications. If we have system enums like WindowsXP, Windows7, Windows10, then we should have functions for isWindows(); otherwise, what will inevitably happen is that another enum is added and every place is the code that uses propositional logic (boolean logic) is potentially broken. I just want to make sure that adding an enum is as easy as updating a small set of functions :) This IMHO is very important to maintainability which for SCons and other long-term projects is a necessity. > > > I have found over and over again people need, as you get more low level, > more detail. But to much detail can be a problem if one does not provide a > good abstraction to replace it. > > > > People need detail something like this is fedora or redhat, or the only > need details such as this is windows or posix. > > > > I know one item I would fix in the Parts Api for SystemPlatform would have > been to move to use of functions for the abstract layers vs string or > enums. Functions such as isX86() or isx86_64(), or isPosix or isLinux() I > think will work better long term as it provides way to say useful stuff > without knowing details that might change in unexpected ways. I have > learned what seems good today probably will not make as much sense > tomorrow, normally for reason we cannot foresee. > +10, +1 isn't enough > > > I should also note maintaining more detail will have a higher maintainer > cost. > Detail is fine as long as the detail has hierarchy; thus, developers can use more/less specific relationships based on need. > > > Jason > > > > > *From: *Russel Winder <[email protected]> > *Sent: *Tuesday, January 19, 2016 5:42 AM > *To: *SCons_Developers <[email protected]> > *Subject: *Re: [Scons-dev] Distinguishing Debian and Fedora > > > > The following is a "doodle" for the direction I think the whole > platform detection thing should go. It is all about removing strings as > selectors, which has to be a bad thing given the propensity of many to > mis-spell things. > > > from enum import Enum, unique > > @unique > class OS_Type(Enum): > posix = 0 > linux_debian = 1 > linux_fedora = 2 > darwin = 3 > windows_win32 = 4 > windows_cygwin = 5 > windows_mingw = 6 > > def which_posix(): > with open('/etc/os-release') as f: > for line in f: > if 'ID' in line: > return { > 'debian': OS_Type.linux_debian, > 'fedora': OS_Type.linux_fedora, > }[line.split('=')[1].strip()] > return OS_Type.posix > > environment = Environment( > tools=('g++', 'gnulink'), > ) > > platform = { > 'posix': which_posix(), > 'darwin': OS_Type.darwin, > }[environment['PLATFORM']] > > environment.MergeFlags('!pkg-config --cflags --libs gtkmm-3.0') > > if platform == OS_Type.linux_fedora: > environment.MergeFlags('!pkg-config --cflags --libs gstreamermm- > 0.10') > elif platform == OS_Type.linux_debian: > environment.MergeFlags('!pkg-config --cflags --libs gstreamermm- > 1.0') > else: > print('Platform not understood.') > Exit(1) > > environment.Program('stuff.cpp', CXXFLAGS=['-std=c++14', '-W', '- > Wall']) > > > > > -- > Russel. > > ============================================================================= > Dr Russel Winder t: +44 20 7585 2200 voip: > sip:[email protected] > 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] > London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder > > > > _______________________________________________ > Scons-dev mailing list > [email protected] > https://pairlist2.pair.net/mailman/listinfo/scons-dev > >
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
