Build errors on windows

[Garrett Bluma]

Just tried to compile "examples/c" with MSVC. There is an error with killableprocess.py. I bypassed this error in the Felix copy of fbuild by switching to generic subprocess.py. That being said we might be losing some functionality by dropping the killable process.

--

Garrett

c:\code\fbuild\examples\c>python c:\code\fbuild\fbuild-light

checking cl.exe          : Traceback (most recent call last):

  File "c:\code\fbuild\fbuild-light", line 13, in <module>

    exec(compile(f.read(), fbuild_exename, 'exec'))

  File "c:\code\fbuild\bin\fbuild", line 162, in <module>

    sys.exit(main())

  File "c:\code\fbuild\bin\fbuild", line 139, in main

    result = build(ctx)

  File "c:\code\fbuild\bin\fbuild", line 82, in build

    target.function(ctx)

  File "c:\code\fbuild\examples\c\fbuildroot.py", line 5, in build

    static = fbuild.builders.c.guess_static(ctx)

  File "c:\code\fbuild\lib\fbuild\builders\c\__init__.py", line 371, in guess_static

    ), *args, **kwargs)

  File "c:\code\fbuild\lib\fbuild\builders\c\__init__.py", line 346, in _guess_builder

    return fbuild.functools.call(function, ctx, *args, **new_kwargs)

  File "c:\code\fbuild\lib\fbuild\functools.py", line 32, in call

    return import_function(function)(*args, **kwargs)

  File "c:\code\fbuild\lib\fbuild\builders\c\msvc.py", line 524, in static

    compiler=Compiler(ctx, Cl(ctx, **kwargs),

  File "c:\code\fbuild\lib\fbuild\db\__init__.py", line 68, in __call__

    *args, **kwargs)

  File "c:\code\fbuild\lib\fbuild\db\database.py", line 162, in call

    call_result = function(*args, **kwargs)

  File "c:\code\fbuild\lib\fbuild\db\__init__.py", line 64, in __call_super__

    return super().__call__(*args, **kwargs)

  File "c:\code\fbuild\lib\fbuild\builders\c\msvc.py", line 38, in __init__

    if not self.check_flags(flags):

  File "c:\code\fbuild\lib\fbuild\builders\c\msvc.py", line 113, in check_flags

    self([src], flags=flags, quieter=1, cwd=src.parent)

  File "c:\code\fbuild\lib\fbuild\builders\c\msvc.py", line 100, in __call__

    return self.ctx.execute(cmd, msg2=msg2, **kwargs)

  File "c:\code\fbuild\lib\fbuild\context.py", line 185, in execute

    **kwargs)

  File "C:\Python34\lib\subprocess.py", line 862, in __init__

    restore_signals, start_new_session)

  File "c:\code\fbuild\lib\fbuild\subprocess\killableprocess.py", line 164, in _execute_child

    winprocess.EnvironmentBlock(env),

  File "c:\code\fbuild\lib\fbuild\subprocess\winprocess.py", line 127, in __init__

    for (key, value) in dict.items()]

AttributeError: 'Path' object has no attribute 'items'

[Ryan Gonzalez]

Let's try this again...

Sorry for the lack of a reply. The mailing list wasn't posting anything I sent (!). So...

I fixed thia. Fbuild on Windows and it seems to work now. At least, the C and C++ builders work with MSVC. MinGW is currently hopelessly lost (I might have fixed one bug remotely but then made another one), and I haven't tested anything else. But it's progress! The main issue was killableprocess.py's code rot. AppVeyor is also (finally) happy.

Now I need to figure out what the f*** is wrong with the Scala builder (it's freezing)...

--
You received this message because you are subscribed to the Google Groups "fbuild" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fbuild+un...@googlegroups.com.
To post to this group, send email to fbu...@googlegroups.com.
Visit this group at http://groups.google.com/group/fbuild.
For more options, visit https://groups.google.com/d/optout.

--

Ryan

[ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong.

http://kirbyfan64.github.io/

 

[rym...@gmail.com]

I replied months ago, but the email was never sent...

I fixed all the Windows issues that I know of and tested fbuild with VS 2010 successfully. MinGW was broken, but I think that might be fixed, although I haven't been able to test it.

[Garrett Bluma]

I've also noticed that python hangs on Windows after it hits an error, I think it has something to do with the way Popen works, but for the moment I'm not super concerned about it. Also it's impossible to debug ephemeral processes... 

Right now I'm just concerned about getting Felix to build.

Anyway, since I have some other Windows specific changes, how should we organize commits? Which repo is master? and what is the merge process? 

Should the fbuild repo be the master copy or are trying to do a multi-master thing?

Also, do we have any rationale about how to structure fbuild, in-the-macro? I can make dozens of small hacks, but they could hurt the overall design.

--

Garrett

On Sat, Jun 6, 2015 at 1:30 PM, <rym...@gmail.com> wrote:

I replied months ago, but the email was never sent...

I fixed all the Windows issues that I know of and tested fbuild with VS 2010 successfully. MinGW was broken, but I think that might be fixed, although I haven't been able to test it.

[Ryan Gonzalez]

On June 10, 2015 5:25:17 PM CDT, Garrett Bluma <garret...@gmail.com> wrote:
>I've also noticed that python hangs on Windows after it hits an error,

Still? I thought I fixed that, too. It happened on Linux. :(

https://github.com/felix-lang/fbuild/issues/11

>I
>think it has something to do with the way Popen works, but for the

I thought it was that the scheduler wasn't being shut down.

Are you using the fixed, now-working killableprocess.py or just subprocess? I know subprocess had some weird issues related to killing processes on Windows.

>moment
>I'm not super concerned about it. Also it's impossible to debug
>ephemeral
>processes...
>
>Right now I'm just concerned about getting Felix to build.

Good luck...

>
>Anyway, since I have some other Windows specific changes, how should we
>organize commits? Which repo is master? and what is the merge process?

Uhh...I'm assuming the following:

- Fbuild repo is master.
- TBD

If you can, could you push your fixes to another branch named windows-stuff or something? I'll take care of merging/rebasing it to master. Or at least what's necessary.

>
>Should the fbuild repo be the master copy or are trying to do a
>multi-master thing?

If you're referring to how Fbuild is also inside the Felix repo, I was just guessing the Felix copy should only be updated when needed, e.g. bugfixes. Main development on the fbuild repo. Note that the main reasons I'm saying this are:

- I think that's how it's been done before.
- Felix takes longer to clone...

Of course, if Skaller wasn't allergic to Git submodules, this could all be avoided... :)

>
>Also, do we have any rationale about how to structure fbuild,
>in-the-macro?
>I can make dozens of small hacks, but they could hurt the overall
>design.
>

Not really sure. I'm just trying to fix it up a little. Erick structured things insanely well, and I don't want to kill that.

That said, it probably more depends on what the small hacks are.

BTW, you know Scala, right? You think you might have an idea about https://github.com/felix-lang/fbuild/issues/15? I am seriously lost as to what it is right now!

>--
>Garrett
>
>
>On Sat, Jun 6, 2015 at 1:30 PM, <rym...@gmail.com> wrote:
>
>> I replied months ago, but the email was never sent...
>>
>> I fixed all the Windows issues that I know of and tested fbuild with
>VS
>> 2010 successfully. MinGW was broken, but I think that might be fixed,
>> although I haven't been able to test it.
>>
>> --
>> You received this message because you are subscribed to the Google
>Groups
>> "fbuild" group.
>> To unsubscribe from this group and stop receiving emails from it,
>send an
>> email to fbuild+un...@googlegroups.com.
>> To post to this group, send email to fbu...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/fbuild.
>> For more options, visit https://groups.google.com/d/optout.
>>

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.