[Scons-dev] mimetypes: adding mimetype for scons scripts

[anatoly techtonik]

On Wed, Jan 28, 2015 at 3:14 PM, Carnë Draug <carandraug+dev at gmail.com> wrote:
> On 23 January 2015 at 17:02, Carnë Draug <carandraug+dev at gmail.com> wrote:
>> On 21 January 2015 at 19:55, Bill Deegan <bill at baddogconsulting.com> wrote:
>>>
>>> On Wed, Jan 21, 2015 at 10:02 AM, Carnë Draug <carandraug+dev at gmail.com>
>>> wrote:
>>>>
>>>> On 21 January 2015 at 13:28, Carnë Draug <carandraug+dev at gmail.com> wrote:
>>>> > On 21 January 2015 at 13:15, Gary Oberbrunner <garyo at oberbrunner.com>
>>>> > wrote:
>>>> >>
>>>> >> On Wed, Jan 21, 2015 at 8:05 AM, Carnë Draug <carandraug+dev at gmail.com>
>>>> >> wrote:
>>>> >>>
>>>> >>> ...
>>>> >>> >>> scons [1] is a build system and I was thinking of adding it to
>>>> >>> >>> shared-mime-info.  Its files are very simple to identify, they are
>>>> >>> >>> always named SConstruct or SConscript.  These files are also valid
>>>> >>> >>> python scripts.
>>>> >>> >>>
>>>> >>> >>> Should shared-mime-info identify them (I can submit a git patch,
>>>> >>> >>> no
>>>> >>> >>> problem)
>>>> >>
>>>> >>
>>>> >> This seems like an easy thing to add, with some possible upside and no
>>>> >> downside.  So why not, I say. Carnë, I think it would be better for you
>>>> >> to
>>>> >> add it to shared-mime-info; SCons could do it but (a) it would be more
>>>> >> complex, and (b) it wouldn't identify SConstructs when SCons isn't
>>>> >> installed.
>>>> >>
>>>> >
>>>> > Yes. shared-mime-info seems to agree with, they only need acceptance
>>>> > from
>>>> > scons developers:
>>>> >
>>>> > On 20 January 2015 at 18:32, Jerome Leclanche <adys.wh at gmail.com> wrote:
>>>> >>
>>>> >> If a text/x-scons mime type is defined and accepted by the SCons devs,
>>>> >> it would then be a sub-type of text/x-python.
>>>> >> J. Leclanche
>>>> >
>>>> > So unless someone opposes I will submit a patch to shared-mime-info.
>>>> > Regarding
>>>> >
>>>> > On 21 January 2015 at 01:28, William Blevins <wblevins001 at gmail.com>
>>>> > wrote:
>>>> >> [...]
>>>> >> SConstruct is a required name, but SConscript is not even though it may
>>>> >> be
>>>> >> the standard/convention.  The subscripts can use any name you like
>>>> >> technically.  I usually include the "*.py" extension so that language
>>>> >> bindings in editors work without setting changes.
>>>> >
>>>> > what if the magic uses the following globs for filenames "SConstruct",
>>>> > "SConscript", and "SConscript.*" ?
>>>>
>>>>
>>>> I have just added a patch for this to bug #87920 [1].  Could someone
>>>> review it please?
>>>>
>>>> I also add 3 new tests based on SCons configuration which I found on the
>>>> repositories for MongoDB, Battle for Wesnoth, and SCons itself.
>>>>
>>>> Carnë
>>>>
>>> I looked at your patch. Looks good. Only thought I had was you could
>>> probably have much more trivial files as the test files.
>>
>> I thought the same at start but then it occurred me that real, more
>> complex cases
>> are better for testing purposes.  The simplest case may be good for test suite
>> of a library but not for identification of a file mimetype.  'Program
>> ("hello.c")'
>> would be a valid SConstruct file but a complex fle with a lot of python makes it
>> ambiguous and more likely to be confused with x-python.
>>
>> Could anyone from shared-mime-info comment or accept my commit? [1]
>>
>> Carnë
>>
>> [1] https://bugs.freedesktop.org/show_bug.cgi?id=87920#c1
>
> For anyone interested, this has now been accepted into shared-mime-info [1].
>
> Carnë
>
> [1] http://cgit.freedesktop.org/xdg/shared-mime-info/commit/?id=29c2eab964cfd8c45fd8a7f5d8407bbc94222095

Cool. Is it possible to add masks, such as SC* with lowered priority so that if
there is no other choice, the SCons type will still be selected? I expect that
some concepts used by GoDot engine could be adopted by other projects
and IDE support for that that could be useful.

This also makes SConscript.* mask unnecessary. I've never seen
files like that, and supporting existing SConscript.py kludges seems
wrong.
-- 
anatoly t.