Re: Distinguishing Debian and Fedora

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